当第一次遇到控制反转(IoC)时,它可能非常令人困惑。
这是怎么一回事?它解决了哪个问题?什么时候使用合适,什么时候不合适?
当第一次遇到控制反转(IoC)时,它可能非常令人困惑。
这是怎么一回事?它解决了哪个问题?什么时候使用合适,什么时候不合适?
当前回答
编程演讲
简单地说,IoC:它是使用接口作为特定对象(例如字段或参数)的一种方式,作为某些类可以使用的通配符。它允许代码的可重用性。
例如,假设我们有两个类:狗和猫。两者具有相同的品质/状态:年龄、体型、体重。因此,我可以创建一个名为AnimalService的服务类,而不是创建一个称为DogService和CatService的服务,它只允许在Dog和Cat使用IAnimal接口时使用它们。
然而,从务实的角度来看,它有一些倒退。
a) 大多数开发人员不知道如何使用它。例如,我可以创建一个名为Customer的类,我可以(使用IDE的工具)自动创建一个称为ICustomer的接口。因此,无论接口是否会被重用,找到一个充满类和接口的文件夹并不罕见。它叫做BLOATED。有些人可能会认为“也许在未来我们可以使用它”-|
b) 它有一些限制。例如,让我们讨论一下Dog和Cat的情况,我想添加一个仅针对狗的新服务(功能)。比方说,我想计算训练一只狗所需的天数(trainDays()),因为猫没用,猫不能训练(我开玩笑)。
b.1)如果我将trainDays()添加到服务AnimalService中,那么它也适用于猫,并且根本无效。
b.2)我可以在trainDays()中添加一个条件,它评估使用的类。但这将彻底打破IoC。
b.3)我可以为新功能创建一个名为DogService的新服务类。但是,这将增加代码的可维护性,因为我们将为Dog提供两类服务(具有类似的功能),这很糟糕。
其他回答
控制反转是用于解耦系统中的组件和层的模式。该模式是通过在构建组件时将依赖项注入组件来实现的。这些依赖性通常作为接口提供,用于进一步去耦和支持可测试性。IoC/DI容器(如Castle Windsor、Unity)是可用于提供IoC的工具(库)。这些工具提供了超越简单依赖管理的扩展功能,包括生存期、AOP/Interception、策略等。a.减轻组件对管理其依赖性的责任。b.提供在不同环境中交换依赖实现的能力。c.允许通过模仿依赖关系来测试组件。d.提供在整个应用程序中共享资源的机制。a.进行测试驱动开发时至关重要。如果没有IoC,很难测试,因为被测组件与系统的其他部分高度耦合。b.开发模块化系统时至关重要。模块化系统是一种无需重新编译即可更换组件的系统。c.如果有许多跨领域的问题需要解决,尤其是在企业应用程序中,则至关重要。
使用IoC,您不会对对象进行更新。您的IoC容器将做到这一点,并管理它们的生命周期。
它解决了必须手动将一种类型对象的每个实例化更改为另一种类型的问题。
如果您的功能将来可能会发生变化,或者根据中使用的环境或配置而有所不同,则使用此选项是合适的。
我在使用库或框架的上下文中想到了控制反转。
传统的“控制”方式是我们构建一个控制器类(通常是主类,但也可以是任何类型的),导入一个库,然后使用您的控制器类来“控制”软件组件的操作。就像你的第一个C/Python程序(继HelloWorld之后)。
import pandas as pd
df = new DataFrame()
# Now do things with the dataframe.
在这种情况下,我们需要知道Dataframe是什么才能使用它。您需要知道要使用什么方法,它的取值方式等等。如果您通过多态性将它添加到自己的类中,或者只是重新调用它,那么您的类将需要Dataframe库才能正常工作。
“控制反转”意味着过程反转。您可以注册类并将其发送回要控制的引擎,而不是您的类控制库、框架或引擎的元素。换句话说,IoC可能意味着我们正在使用代码来配置框架。您也可以将其视为类似于我们在map或filter中使用函数来处理列表中的数据的方式,只是将其应用于整个应用程序。
如果您是构建引擎的人,那么您可能正在使用依赖注入方法(如上所述)来实现这一点。如果你是一个使用引擎的人(更常见),那么你应该能够只声明类,添加适当的符号,让框架为你完成剩下的工作(例如创建路由、分配servlet、设置事件、输出小部件等)。
什么是控制反转?
如果您遵循这两个简单的步骤,您就完成了控制反转:
把该做什么和什么时候该做分开。确保零件何时尽可能少地了解什么零件;反之亦然。
根据您用于实现的技术/语言,这些步骤中的每一个都有几种可能的技术。
--
控制反转(IoC)的反转部分令人困惑;因为反转是相对项。了解IoC的最好方法是忘记这个词!
--
示例
事件处理。事件处理程序(做什么部分)--引发事件(何时做部分)依赖注入。构造依赖项(做什么部分)的代码——在需要时为客户机实例化和注入依赖项,这通常由Dagger等DI工具来处理(什么时候做部分)。接口。组件客户端(何时执行部分)--组件接口实现(执行部分)x装置夹具。Setup和TearDown(要做的部分)--xUnit框架在开始时调用Setup,在结束时调用TearDown(何时做部分)模板方法设计模式。模板方法何时执行部分--基本子类实现何时执行部分COM.DllMain、DllCanUnload等中的DLL容器方法(做什么部分)--COM/OS(什么时候做部分)
控制反转是将控制权从库转移到客户端。当我们讨论将函数值(lambda表达式)注入(传递)到控制(改变)库函数行为的高阶函数(库函数)中的客户端时,它更有意义。
因此,这个模式的一个简单实现(具有巨大的含义)是一个更高阶的库函数(它接受另一个函数作为参数)。库函数通过赋予客户端提供“控制”函数作为参数的能力来传递对其行为的控制。
例如,“map”、“flatMap”等库函数是IoC实现。
当然,例如,有限的IoC版本是布尔函数参数。客户端可以通过切换布尔参数来控制库函数。
将库依赖项(承载行为)注入到库中的客户端或框架也可以被视为IoC