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.