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

[b]Inversion of Control（控制反转，IoC）[/b]
大家可能已经知道[b]好莱坞（Hollywood）原则[/b]：
[table]
|[b][color=darkblue]Don’t call us, we’ll call you.[/color][/b]|
|[b][color=darkblue]不要找我们，我们会找你。[/color][/b]|
[/table]
好莱坞原则在软件开发领域中极受追捧：我们经常把控制逻辑写在其他地方（例如Framework）而非客户化的代码里，我们就更专注于客户化的逻辑，也就是说，外部逻辑负责调用我们客户化的逻辑。[b]在软件开发领域，我们又给它取了一个名字叫控制反转（IoC）[/b][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显示的逻辑。

[b]IoC和DI（Dependency Injection，依赖注入）[/b]
后来，随着轻量级容器/框架不停地涌现，控制反转的概念越来越被开发人员提及，很多轻量级容器/框架标榜使用到的控制反转，其实通过上述介绍我们知道，任何容器/框架都实现了控制反转。它们所说的控制反转指的是对服务/对象/组件的实例化和查找实现了控制反转，这只是控制反转的一种而已。关于这方面的控制反转主要有两种形式：Service Locator（服务定位器）和Dependency Injection（依赖注入，简写为DI），关于这两种形式的讨论，请参见[url=http://redhat.iteye.com/blog/1007884]漫谈设计模式第6章[/url]。

[b]标注[/b]
[color=blue][b][1][/b][/color] 这个短语首先在Johnson and Foote撰写的论文[url=http://www.laputan.org/drc/drc.html]Designing Reusable Classes[/url]使用到。

[b]参考文献：[/b]
[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.