IoC容器和依赖注入模式（转载）

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

 

摘要：Java社群近来掀起了一阵轻量级容器的热潮，这些容器能够帮助开发者将来自不同项目的组件组装成为一个内聚的应用程序。在它们的背后有着同一个模式，这个模式决定了这些容器进行组件装配的方式。人们用一个大而化之的名字来称呼这个模式：“控制反转”（ Inversion of Control，IoC）。在本文中，我将深入探索这个模式的工作原理，给它一个更能描述其特点的名字——“依赖注入”（Dependency Injection），并将其与“服务定位器”（Service Locator）模式作一个比较。不过，这两者之间的差异并不太重要，更重要的是：应该将组件的配置与使用分离开——两个模式的目标都是这个。
 

目录

组件和服务
一个简单的例子
控制反转
依赖注入的几种形式
    使用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。

class MovieLister...
    public Movie[] moviesDirectedBy(String arg)
    {
        List allMovies = finder.findAll();
        for (Iterator it = allMovies.iterator(); it.hasNext();)
        {
            Movie movie = (Movie) it.next();
            if (!movie.getDirector().equals(arg))
            {
                it.remove();
            }
        }
        return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
    }