当第一次遇到控制反转(IoC)时,它可能非常令人困惑。

这是怎么一回事?它解决了哪个问题?什么时候使用合适,什么时候不合适?


当前回答

IoC原则有助于设计松散耦合的类,使其可测试、可维护和可扩展。

其他回答

这是怎么一回事?反转(耦合)控制,更改方法签名的耦合方向。对于反向控制,方法签名的定义由方法实现(而不是方法的调用方)决定。此处完整解释

它解决了哪个问题?方法上的自顶向下耦合。这随后消除了重构的需要。

什么时候使用合适,什么时候不合适?对于定义良好的小型应用程序,如果没有太大的变化,可能会产生开销。然而,对于将要发展的定义较少的应用程序,它减少了方法签名的固有耦合。这使开发人员可以更自由地开发应用程序,避免了对代码进行昂贵的重构。基本上,允许应用程序在很少返工的情况下发展。

控制反转是一个通用原则,而依赖注入将这一原则实现为对象图构造的设计模式(即配置控制对象如何相互引用,而不是对象本身控制如何获取对另一个对象的引用)。

将控制反转视为一种设计模式,我们需要看看我们正在反转什么。依赖注入反转了对构建对象图的控制。如果用外行的术语来说,控制反转意味着程序中控制流的改变。例如,在传统的独立应用程序中,我们有一个主要的方法,从那里控制权被传递给其他第三方库(在这种情况下,我们使用了第三方的库的功能),但通过控制反转,控制权从第三方程序库代码转移到我们的代码,因为我们正在使用第三方代码库的服务。但在程序中还有其他方面需要反转,例如调用方法和线程来执行代码。

对于那些对控制反转感兴趣的人来说,已经发表了一篇论文,概述了控制反转作为一种设计模式的更完整的图景(OfficeFloor:使用办公模式来改进软件设计http://doi.acm.org/10.1145/2739011.2739013免费下载http://www.officefloor.net/about.html).

确定的关系如下:

控制反转(用于方法)=依赖(状态)注入+连续注入+线程注入

可用控制反转的上述关系汇总http://dzone.com/articles/inversion-of-coupling-control

我知道这里已经给出了答案。但我仍然认为,关于控制反转的一些基础知识必须在这里详细讨论,以供未来读者参考。

控制反转(IoC)建立在一个叫做好莱坞原理的非常简单的原理上。上面说,

不要给我们打电话,我们会给你打电话

这意味着不要去好莱坞实现你的梦想,如果你值得,那么好莱坞会找到你,让你的梦想成真。差不多颠倒了,嗯?

现在,当我们讨论IoC的原理时,我们常常忘记好莱坞。对于IoC来说,必须有三个要素,一个好莱坞,一个你和一个完成你梦想的任务。

在我们的编程世界中,Hollywood代表一个通用框架(可能由您或其他人编写),您代表您编写的用户代码,任务代表您希望用代码完成的任务。现在,你永远不会自己触发任务,而不是在IoC!相反,你已经设计好了所有的东西,这样你的框架就会触发你的任务。因此,您已经构建了一个可重用的框架,它可以使某人成为英雄或另一人成为恶棍。但这一框架始终处于主导地位,它知道什么时候该挑选某人,而某人只知道自己想要成为什么样的人。

这里将给出一个真实的例子。假设您想开发一个web应用程序。因此,您可以创建一个框架来处理web应用程序应该处理的所有常见事务,如处理http请求、创建应用程序菜单、服务页面、管理cookie、触发事件等。

然后你在你的框架中留下一些钩子,你可以在那里放置更多的代码来生成自定义菜单、页面、cookie或记录一些用户事件等。在每次浏览器请求时,你的框架都会运行并执行你的自定义代码,如果勾住了,然后将其发送回浏览器。

所以,这个想法非常简单。与其创建一个控制一切的用户应用程序,不如先创建一个可重用的框架来控制一切,然后编写自定义代码并将其连接到框架以及时执行这些代码。

Laravel和EJB就是这样一个框架的例子。

参考:

https://martinfowler.com/bliki/InversionOfControl.html

https://en.wikipedia.org/wiki/Inversion_of_control

为了理解这个概念,控制反转(IoC)或依赖反转原理(DIP)涉及两个活动:抽象和反转。依赖注入(DI)只是为数不多的反转方法之一。

要了解更多信息,您可以在此处阅读我的博客

这是怎么一回事?

这是一种让实际行为来自边界之外的实践(面向对象编程中的类)。边界实体只知道它的抽象(例如面向对象编程中的接口、抽象类、委托)。

它解决了什么问题?

在编程方面,IoC试图通过使单片代码模块化、解耦其各个部分并使其可单元测试来解决单片代码。

什么时候合适,什么时候不合适?

这在大多数情况下都是合适的,除非您有只需要单片代码的情况(例如非常简单的程序)

控制反转是将控制权从库转移到客户端。当我们讨论将函数值(lambda表达式)注入(传递)到控制(改变)库函数行为的高阶函数(库函数)中的客户端时,它更有意义。

因此,这个模式的一个简单实现(具有巨大的含义)是一个更高阶的库函数(它接受另一个函数作为参数)。库函数通过赋予客户端提供“控制”函数作为参数的能力来传递对其行为的控制。

例如,“map”、“flatMap”等库函数是IoC实现。

当然,例如,有限的IoC版本是布尔函数参数。客户端可以通过切换布尔参数来控制库函数。

将库依赖项(承载行为)注入到库中的客户端或框架也可以被视为IoC