IoC != 装配和实例化的反转 != DI(注射依赖)

前端之家收集整理的这篇文章主要介绍了IoC != 装配和实例化的反转 != DI(注射依赖)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Inversion of Control(控制反转,IoC)
大家可能已经知道 好莱坞(Hollywood)原则
Don’t call us,we’ll call you.
不要找我们,我们会找你。

好莱坞原则在软件开发领域中极受追捧:我们经常把控制逻辑写在其他地方(例如Framework)而非客户化的代码里,我们就更专注于客户化的逻辑,也就是说,外部逻辑负责调用我们客户化的逻辑。 在软件开发领域,我们又给它取了一个名字叫控制反转(IoC) [1]。

控制反转概念的涉及面十分广泛,有人认为它是一个模式,但是我更倾向于认为它是一个原则(Principle)。很多模式都实现了控制反转(例如模板方法模式),例如,我们第2章讲解的模板方法模式就是控制反转的一个很好应用,父类的模板方法控制子类的方法调用;还有,使用回调的方法都是控制反转的很好应用。
再如,在Java标准库里,我们常用到查找和排序的这两个方法,binarySearch(…)和sort(…)方法,它们在执行过程中会调用对象的compareTo()方法(如果这些对象实现了java.lang.Comparable接口的话),或者调用我们所传递的回调接口java.util.Comparator对象的compare()方法来比较大小,最终完成查找/排序操作,这些都是控制反转的例子。
此外,我们经常提到的框架(Framework),它最典型的特点其实就是控制反转:框架抽象了通用流程,我们可以通过框架提供的规范(比如子类化抽象类或者实现相关的接口,实现相关的交互协议和接口等等)就可以把客户化的代码植入流程中,完成各种定制的需求。框架和工具库(Library)的区别是:如果框架没有实现控制反转,那么框架就会退化为工具库。也就是说,使用工具库,你必须撰写调用它们的逻辑,每次调用它们都会完成相应的工作,并把控制权返回给调用者;而框架不需要客户程序撰写控制调用的逻辑,由框架专门负责。
以我们时下非常流行的MVC框架Struts为例,我们只需要实现相关的Action,Form类以及相关View,并配置好Action-Form-View的映射关系,这样每次客户端提交请求,该框架都会选择相应的Action去处理它,并根据返回的执行结果选择相应的视图。这些控制逻辑由Struts框架为我们完成了,不需要我们实现如何调用相应Action执行的逻辑,也不需要实现如何选择View显示的逻辑。
IoC和DI(Dependency Injection,依赖注入) 后来,随着轻量级容器/框架不停地涌现,控制反转的概念越来越被开发人员提及,很多轻量级容器/框架标榜使用到的控制反转,其实通过上述介绍我们知道,任何容器/框架都实现了控制反转。它们所说的控制反转指的是对服务/对象/组件的实例化和查找实现了控制反转,这只是控制反转的一种而已。关于这方面的控制反转主要有两种形式:Service Locator(服务定位器)和Dependency Injection(依赖注入,简写为DI),关于这两种形式的讨论,请参见 漫谈设计模式第6章
标注 [1] 这个短语首先在Johnson and Foote撰写的论文 Designing Reusable Classes 使用到。
参考文献: [1] Martin Fowler. InversionOfControl. Web site: http://martinfowler.com/bliki/InversionOfControl.html. 2005.
[2] Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern. Web site: http://martinfowler.com/articles/injection.html. 2004.

猜你在找的设计模式相关文章