编者语：最近研究IoC，在网上搜索到很多网页推荐阅读Martin Fowler的一篇名叫Inversion of Control Containers and the Dependency Injection pattern的文章。点击到该文章页面便吓了一跳：这什么文章啊，简单一个网页PageRank居然是7！要知道，国内几大门户网站也都还没有到这个值呢！也难怪，Martin Fowler被誉为软件开发教父，他的文章，肯定有N多人拜读。细细读来，感觉大师确实很厉害，文章条理清晰，论证深入，结论明确！本想将此好文翻译推荐给广大网友，可在网上一搜，早有前人将其翻译成中文了。这里，我将网上流传的中文版整理后，推荐给广大的编程爱好者，希望大师的精彩讲解能够让你对相关问题有一个透彻的理解。同时，我还将其整理成了Word文档，需要的朋友点这里下载。

目录

组件和服务
一个简单的例子
控制反转
依赖注入的几种形式
使用PicoContainer进行构造函数注入
使用Spring进行设值方法注入
接口注入
使用Service Locator
为定位器提供分离的接口
动态服务定位器
用Avalon兼顾服务定位器和依赖注入
作出一个选择
Service Locator vs. Dependency Injection
构造函数注入vs.设值方法注入
代码配置vs.配置文件
分离配置与使用
更多的问题
结论和思考
致谢

在企业级Java的世界里存在一个有趣的现象：有很多人投入很多精力来研究主流J2EE技术的替代品——自然，这大多发生在open source社群。在很大程度上，这可以看作是开发者对主流J2EE技术的笨重和复杂作出的回应，但其中的确有很多极富创意的想法，的确提供了一些可供选择的方案。J2EE开发者常遇到的一个问题就是如何组装不同的程序元素：如果web控制器体系结构和数据库接口是由不同的团队所开发的，彼此几乎一无所知，你应该如何让它们配合工作？很多框架尝试过解决这个问题，有几个框架索性朝这个方向发展，提供了更通用的“组装各层组件”的方案。这样的框架通常被称为“轻量级容器”，PicoContainer和Spring都在此列中。

在这些容器背后，一些有趣的设计原则发挥着作用。这些原则已经超越了特定容器的范畴，甚至已经超越了Java平台的范畴。在本文中，我就要初步揭示这些原则。我使用的范例是Java代码，但正如我的大多数文章一样，这些原则也同样适用于别的OO环境，特别是.NET。

组件和服务

装配程序元素，这样的话题立即将我拖进了一个棘手的术语问题：如何区分“服务”（service）和“组件”（component）？你可以毫不费力地找出关于这两个词定义的长篇大论，各种彼此矛盾的定义会让你感受到我所处的窘境。有鉴于此，对于这两个遭到了严重滥用的词汇，我将首先说明它们在本文中的用法。

所谓“组件”是指这样一个软件单元：它将被作者无法控制的其他应用程序使用，但后者不能对组件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但可以通过作者预留的某种途径对其进行扩展，以改变组件的行为。

服务和组件有某种相似之处：它们都将被外部的应用程序使用。在我看来，两者之间最大的差异在于：组件是在本地使用的（例如JAR文件、程序集、DLL、或者源码导入）；而服务是要通过同步或异步的远程接口来远程使用的（例如web service、消息系统、RPC，或者socket）。

在本文中，我将主要使用“服务”这个词，但文中的大多数逻辑也同样适用于本地组件。实际上，为了方便地访问远程服务，你往往需要某种本地组件框架。不过，“组件或者服务”这样一个词组实在太麻烦了，而且“服务”这个词当下也很流行，所以本文将用“服务”指代这两者。

一个简单的例子

为了更好地说明问题，我要引入一个例子。和我以前用的所有例子一样，这是一个超级简单的例子：它非常小，小得有点不够真实，但足以帮助你看清其中的道理，而不至于陷入真实例子的泥潭中无法自拔。

在这个例子中，我编写了一个组件，用于提供一份电影清单，清单上列出的影片都是由一位特定的导演执导的。实现这个伟大的功能只需要一个方法：

你可以看到，这个功能的实现极其简单：moviesDirectedBy方法首先请求finder（影片搜寻者）对象（我们稍后会谈到这个对象）返回后者所知道的所有影片，然后遍历finder对象返回的清单，并返回其中由特定的某个导演执导的影片。非常简单，不过不必担心，这只是整个例子的脚手架罢了。我们真正想要考察的是finder对象，或者说，如何将MovieLister对象与特定的finder对象连接起来。为什么我们对这个问题特别感兴趣？因为我希望上面这个漂亮的moviesDirectedBy方法完全不依赖于影片的实际存储方式。所以，这个方法只能引用一个finder对象，而finder对象则必须知道如何对findAll方法作出回应。为了帮助读者更清楚地理解，我给finder定义了一个接口：

现在，两个对象之间没有什么耦合关系。但是，当我要实际寻找影片时，就必须涉及到MovieFinder的某个具体子类。在这里，我把涉及具体子类的代码放在MovieLister类的构造函数中。

这个实现类的名字就说明：我将要从一个逗号分隔的文本文件中获得影片列表。你不必操心具体的实现细节，只要设想这样一个实现类就可以了。如果这个类只由我自己使用，一切都没问题。但是，如果我的朋友叹服于这个精彩的功能，也想使用我的程序，那又会怎么样呢？如果他们也把影片清单保存在一个逗号分隔的文本文件中，并且也把这个文件命名为“ movie1.txt ”，那么一切还是没问题。如果他们只是给这个文件改改名，我也可以从一个配置文件获得文件名，这也很容易。但是，如果他们用完全不同的方式——例如SQL数据库、XML文件、web service，或者另一种格式的文本文件——来存储影片清单呢？在这种情况下，我们需要用另一个类来获取数据。由于已经定义了MovieFinder接口，我可以不用修改moviesDirectedBy方法。但是，我仍然需要通过某种途径获得合适的MovieFinder实现类的实例。

图1：在MovieLister类中直接创建MovieFinder实例时的依赖关系

图1展现了这种情况下的依赖关系：MovieLister类既依赖于MovieFinder接口，也依赖于具体的实现类。我们当然希望MovieLister类只依赖于接口，但我们要如何获得一个MovieFinder子类的实例呢？

在《Patterns of Enterprise Application Architecture》一书中，我们把这种情况称为插件（plugin）：MovieFinder的实现类不是在编译期连入程序之中的，因为我并不知道我的朋友会使用哪个实现类。我们希望MovieLister类能够与MovieFinder的任何实现类配合工作，并且允许在运行期插入具体的实现类，插入动作完全脱离我（原作者）的控制。这里的问题就是：如何设计这个连接过程，使MovieLister类在不知道实现类细节的前提下与其实例协同工作。

将这个例子推而广之，在一个真实的系统中，我们可能有数十个服务和组件。在任何时候，我们总可以对使用组件的情形加以抽象，通过接口与具体的组件交流（如果组件并没有设计一个接口，也可以通过适配器与之交流）。但是，如果我们希望以不同的方式部署这个系统，就需要用插件机制来处理服务之间的交互过程，这样我们才可能在不同的部署方案中使用不同的实现。所以，现在的核心问题就是：如何将这些插件组合成一个应用程序？这正是新生的轻量级容器所面临的主要问题，而它们解决这个问题的手段无一例外地是控制反转（Inversion of Control）模式。

控制反转

几位轻量级容器的作者曾骄傲地对我说：这些容器非常有用，因为它们实现了控制反转。这样的说辞让我深感迷惑：控制反转是框架所共有的特征，如果仅仅因为使用了控制反转就认为这些轻量级容器与众不同，就好象在说我的轿车是与众不同的，因为它有四个轮子。

问题的关键在于：它们反转了哪方面的控制？我第一次接触到的控制反转针对的是用户界面的主控权。早期的用户界面是完全由应用程序来控制的，你预先设计一系列命令，例如输入姓名、输入地址等，应用程序逐条输出提示信息，并取回用户的响应。而在图形用户界面环境下，UI框架将负责执行一个主循环，你的应用程序只需为屏幕的各个区域提供事件处理函数即可。在这里，程序的主控权发生了反转：从应用程序移到了框架。对于这些新生的容器，它们反转的是如何定位插件的具体实现。在前面那个简单的例子中，MovieLister类负责定位MovieFinder的具体实现——它直接实例化后者的一个子类。这样一来，MovieFinder也就不成其为一个插件了，因为它并不是在运行期插入应用程序中的。而这些轻量级容器则使用了更为灵活的办法，只要插件遵循一定的规则，一个独立的组装模块就能够将插件的具体实现注射到应用程序中。因此，我想我们需要给这个模式起一个更能说明其特点的名字——“控制反转”这个名字太泛了，常常让人有些迷惑。与多位IoC爱好者讨论之后，我们决定将这个模式叫做“依赖注入”（Dependency Injection）。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!