控制反转容器与依赖注入模式（转） 控制反转 依赖注入

使用 PicoContainer 进行构造函数注入

首先，我要展示如何用轻量级容器 PicoContainer 完成依赖注入。之所以从它开始，主要是因为我在 ThoughtWorks 公司的几个同事在 PicoContainer的开发社区中非常活跃（没错，也可以说是某种偏袒吧）。

PicoContainer 使用构造函数来决定如何将 MovieFinder 实例注入 MovieLister 类。因此，MovieLister 类必须声明一个包含所有需要注入的元素的构造函数。

也就是说，所有需要注入的元素，是构造函数的形式参数。

MovieLister 类：

public MovieLister(MovieFinder finder) {
      this.finder = finder;       
  }

MovieFinder 实例本身也将由 PicoContainer 来管理，因此本文文件的名字也可以由容器注入：

ColonMovieFinder 类：

 public ColonMovieFinder(String filename) {
      this.filename = filename;
  }

然后，需要告诉 pico 容器每个接口分别与哪个实现类相关联，将什么字符串注入到 MovieFinder 组件。

private MutablePicoContainer configureContainer() {
    MutablePicoContainer pico = new DefaultPicoContainer();
    Parameter[] finderParams =  {new ConstantParameter("movies1.txt")};
    pico.registerComponentImplementation(MovieFinder.class, ColonMovieFinder.class, finderParams);
    pico.registerComponentImplementation(MovieLister.class);
    return pico;
}

这段配置代码通常位于另一个类。对于我们这个例子，使用我 MovieLister 类的朋友需要在自己的设置类中编写合适的配置代码。当然，还可以将这些配置信息放在一个单独的配置文件中，这也是一种常见的做法。你可以编写一个类来读取配置文件，然后对容器进行适当的设置。尽管 PicoContainer 本身并不包含这项功能，但另一个与它关系密切的项目 NanoContainer 提供了一些包装，允许开发者使用 XML 配置文件保存配置信息。NanoContainer 能够解析 XML 文件，并对底下的 PicoContainer 进行配置。这个项目的哲学就是：将配置文件的格式与底下的配置机制分离。

使用这个容器，你的代码大概是这样：

public void testWithPico() {
    MutablePicoContainer pico = configureContainer();
    MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}

尽管本例我使用了构造函数注入，实际上 PicoContainer 也支持设置方法注入，不过该项目的开发者更推荐使用构造函数注入。

使用Spring框架进行属性注入

Spring 是一个用途广泛的企业级 Java 开发框架，其中包括了针对事务、持久化、Web 应用开发和 JDBC 等常用功能的抽象。与 PicoContainer 一样，它同时支持构造函数注入和设置方法注入，但该项目的开发者更推荐使用 setter 方法注入——恰好适合这个例子。

为了让 MovieLister 类接受注入，我需要为它定义一个 setter 方法，该方法接受类型为 MovieFinder 的参数：

MovieLister 类：

private MovieFinder finder;
public void setFinder(MovieFinder finder) {
  this.finder = finder;
}

类似地，在 MovieFinder 的实现类中，也定义了一个 setter 方法，接受类型为 String：

ColonMovieFinder 类：

public void setFilename(String filename) {
      this.filename = filename;
  }

第三步是设置配置文件。Spring 支持多种配置方式，可以通过 XML 文件进行，也可以直接在代码中配置。不过，XML 文件是比较理想的配置方式。

<beans>
    <bean id="MovieLister" class="spring.MovieLister">
        <property name="finder">
            <ref local="MovieFinder"/>
        </property>
    </bean>
    <bean id="MovieFinder" class="spring.ColonMovieFinder">
        <property name="filename">
            <value>movies1.txt</value>
        </property>
    </bean>
</beans>

于是，测试代码大概像下面这样：

public void testWithSpring() throws Exception {
    ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");
    MovieLister lister = (MovieLister) ctx.getBean("MovieLister");
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}

接口的依赖注入

除了前面两种注入技术，还可以在接口中定义需要注入的信息，并通过接口完成注入。Avalon 框架就使用了类似的技术。在这里，我首先用简单的范例代码说明它的用法，后面还会有更深入的讨论。

public interface InjectFinder {
    void injectFinder(MovieFinder finder);
}

首先，我需要定义一个接口，组件的注入将通过这个接口进行。在本例中，这个接口的用途是将一个 MovieFinder 实例注入继承了该接口的对象。

MovieLister 类实现了 InjectFinder 方法：

public void injectFinder(MovieFinder finder) {
      this.finder = finder;
  }

这个接口应该由提供 MovieFinder 接口的人一并提供。任何想要使用 MovieFinder 实例的类，例如 MovieLister，都必须实现这个接口。

public interface InjectFinderFilename {
    void injectFilename (String filename);
}

然后，我使用类似的方法将文件名注入 MovieFinder 的实现类：

 public void injectFilename(String filename) {
      this.filename = filename;
  }

现在，还需要用一些配置代码将所有的组件实现装配起来。简单起见，我直接在代码中完成配置，并将配置好的 MovieLister 对象保存在名为 lister 的字段中：

Tester 类：

   private Container container;

   private void configureContainer() {
     container = new Container();
     registerComponents();
     registerInjectors();
     container.start();
  }

这个配置分两个阶段，通过查找键来注册组件，跟其他示例相当类似。

Tester 类：

 private void registerComponents() {
    container.registerComponent("MovieLister", MovieLister.class);
    container.registerComponent("MovieFinder", ColonMovieFinder.class);
  }

接下来是注册注入，注入独立的组件。每次注射接口需要一些代码注入依赖对象。本例，用 container 注册注入组件。每个注入对象都实现了注入接口

Tester 类：

private void registerInjectors() {
    container.registerInjector(InjectFinder.class, container.lookup("MovieFinder"));
    container.registerInjector(InjectFinderFilename.class, new FinderFilenameInjector());
}
public interface Injector {
  public void inject(Object target);
}

当依赖是这个容器的一个内部类时，它有必要实现注入接口本身，正如我下面定义的 MovieFiender 类。对于泛型类，如字符串，我在配置代码中使用内部类。

ColonMovieFinder 类实现了 Injector 方法：

public void inject(Object target) {
    ((InjectFinder) target).injectFinder(this);        
}

Tester 类：

public static class FinderFilenameInjector implements Injector {
    public void inject(Object target) {
      ((InjectFinderFilename)target).injectFilename("movies1.txt");      
    }
}

下面使用容器来进行测试。

IfaceTester 类：

public void testIface() {
    configureContainer();
    MovieLister lister = (MovieLister)container.lookup("MovieLister");
    Movie[] movies = lister.moviesDirectedBy("Sergio Leone");
    assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}

容器使用声明的注入接口来计算依赖关系和注入器以注入正确的依赖关系。这里的具体的容器接口实现对这一技术不重要，我将不显示它，以免你觉得好笑。

为服务定位器使用分离接口

上面这种简单的实现方式有一个问题，MovieLister 类将依赖于整个 ServiceLocator 类，但它需要使用的却只是后者提供的一项服务。我们可以针对这项服务提供一个单独的接口，减少 MovieLister 对 ServiceLocator 的依赖程度。这样一来，MovieLister就不必使用整个的 ServiceLocator 接口，只需要声明它想要使用的那部分接口。

此时，MovieLister 类的提供者也应该一并提供一个定位器接口，使用者可以通过这个接口获得 MovieFinder 实例。

public interface MovieFinderLocator {
    public MovieFinder movieFinder();
}

真实的服务定位器需要实现上述接口，提供访问 MovieFinder 实例的能力：

MovieFinderLocator locator = ServiceLocator.locator();
MovieFinder finder = locator.movieFinder();
public static ServiceLocator locator() {
     return soleInstance;
 }
public MovieFinder movieFinder() {
    return movieFinder;
}
private static ServiceLocator soleInstance;
private MovieFinder movieFinder;

你应该已经注意到了，由于想要使用接口，我们不能再通过静态方法直接访问服务——我么必须首先通过 ServiceLocator 类获得定位器实例，然后使用定位器实例得到我们想要的服务。

一个动态的服务定位器

上面是一个静态定位器的例子，对于你所需要的每项服务，ServiceLocator 类都有对应的方法。这并不是实现服务定位器的唯一方式，你也可以创建一个动态服务定位器，你可以在其中注册需要的任何服务，并在运行时决定获得哪像服务。

在本例中，ServiceLocator 使用一个 map 来保存服务信息，而不再是将这些信息保存在字段中。此外，ServiceLocator 还提供了一个 通用的方法，用于获取和加载服务对象。

ServiceLocator 类：

  private static ServiceLocator soleInstance;
  public static void load(ServiceLocator arg) {
      soleInstance = arg;
  }
  private Map services = new HashMap();
  public static Object getService(String key){
      return soleInstance.services.get(key);
  }
  public void loadService (String key, Object service) {
      services.put(key, service);
  }

同样需要对服务定位器进行配置，将服务对象与适当的关键字加载到定位器中：

Tester 类：

  private void configure() {
      ServiceLocator locator = new ServiceLocator();
      locator.loadService("MovieFinder", new ColonMovieFinder("movies1.txt"));
      ServiceLocator.load(locator);
  }

我使用与服务对象类名称相同的字符串作为服务对象的关键字：

MovieLister 类：

MovieFinder finder = (MovieFinder) ServiceLocator.getService("MovieFinder");

总体而言，我不喜欢这种方式。无疑，这样实现的服务定位器具有更强的灵活性，但它的使用方式不够直观明朗。我只有通过文本形式的关键字才能找到一个服务对象。相比之下，我更欣赏通过一个方法获得服务对象的方式，因为这让使用者能够从接口定义中清楚地知道如何获得某项服务。

在 Avalon 中使用服务定位器和依赖注入

Dependency Injection 和 Service Locator 两个模式并不是互斥的，你可以同时使用它们，Avalon 框架就是这样的一个例子。Avalon 使用了服务定位器，但如何获得定位器的信息则是通过注入的方式告知组件的。
对于前面一直使用的例子，Berin Loritsch 发送给了我一个简单的 Avalon 实现版本：

public class MyMovieLister implements MovieLister, Serviceable {
    private MovieFinder finder;

    public void service( ServiceManager manager ) throws ServiceException {
        finder = (MovieFinder)manager.lookup("finder");
    }
}

service 方法就是接口注入的例子，它使容器可以将一个 ServiceManager 对象注入 MyMovieLister 对象。ServiceManager 则是一个服务定位器。在这个例子中，MyMovieLister 并不把 ServiceManager 对象保存在字段中，而是马上借助它找到MovieFinder 实例，并将后者保存起来。

服务定位 vs 依赖注入

首先， 我们面临 Service Locator 和 Dependency Injection 之间的选择。 应该注意， 尽管我们前面那个简单的例子不足以表现出来， 实际上这两个模式都提供了基本的解耦合能力。无论使用哪个模式， 应用程序代码都不依赖于服务接口的具体实现。两者之间最重要的区别在于：具体实现以什么方式提供给应用程序代码。使用 Service Locator 模式时，应用程序代码直接向服务定位器发送一个消息，明确要求服务的实现；使用 Dependency Injection 模式时，应用程序代码不发出显式的请求，服务的实现自然会出现在应用程序代码中，这也就是所谓控制反转。
控制反转是框架的共同特征，但它也要求你付出一定的代价：它会增加理解的难度，并且给调试带来一定的困难。所以，整体来说，除非必要，否则我会尽量避免使用它。这并不意味着控制反转不好，只是我认为在很多时候使用一个更为直观的方案（例如 Service Locator 模式）会比较合适。
一个关键的区别在于：使用 Service Locator 模式时，服务的使用者必须依赖于服务定位器。定位器可以隐藏使用者对服务具体实现的依赖，但你必须首先看到定位器本身。所以，问题的答案就很明朗了：选择 Service Locator 还是 Dependency Injection ，取决于对定位器的依赖是否会给你带来麻烦。
Dependency Injection 模式可以帮助你看清组件之间的依赖关系：你只需观察依赖注入的机制（例如构造函数），就可以掌握整个依赖关系。而使用 Service Locator 模式时，你就必须在源代码中到处搜索对服务定位器的调用。具备全文检索能力的 IDE 可以略微简化这一工作，但还是不如直接观察构造函数或者设值方法来得轻松。
这个选择主要取决于服务使用者的性质。如果你的应用程序中有很多不同的类要使用一个服务，那么应用程序代码对服务定位器的依赖就不是什么大问题。在前面的例子中， 我要把MovieLister 类交给朋友去用，这种情况下使用服务定位器就很好：我的朋友们只需要对定位器做一点配置（通过配置文件或者某些配置性的代码），使其提供合适的服务实现就可以了。在这种情况下，我看不出Dependency Injection 模式提供的控制反转有什么吸引人的地方。
但是，如果把 MovieLister 看作一个组件，要将它提供给别人写的应用程序去使用，情况就不同了。在这种时候，我无法预测使用者会使用什么样的服务定位器API，每个使用者都可能有自己的服务定位器，而且彼此之间无法兼容。一种解决办法是为每项服务提供单独的接口，使用者可以编写一个适配器，让我的接口与他们的服务定位器相配合。但即便如此，我仍然需要到第一个服务定位器中寻找我规定的接口。而且一旦用上了适配器，服务定位器所提供的简单性就被大
大削弱了。
另一方面，如果使用 Dependency Injection 模式，组件与注入器之间不会有依赖关系，因此组件无法从注入器那里获得更多的服务，只能获得配置信息中所提供的那些。这也是 Dependency Injection 模式的局限性之一。
人们倾向于使用 Dependency Injection 模式的一个常见理由是：它简化了测试工作。这里的关键是：出于测试的需要，你必须能够轻松地在真实的服务实现与供测试用的伪组件之间切换。但是，如果单从这个角度来考虑，Dependency Injection 模式和 Service Locator 模式其实并没有太大区别： 两者都能够很好地支持伪组件的插入。之所以很多人有 Dependency Injection 模式更利于测试的印象，我猜是因为他们并没有努力保证服务定位器的可替换性。这正是持续测试起作用的地方：如果你不能轻松地用一些伪组件将一个服务架起来以便测试，这就意味着你的设计出现了严重的问题。
当然，如果组件环境具有非常强的侵略性（就像 EJB 框架那样），测试的问题会更加严重。我的观点是：应该尽量减少这类框架对应用程序代码的影响，特别是不要做任何可能使编辑-执行的循环变慢的事情。用插件（plugin）机制取代重量级组件会对测试过程有很大帮助，这正是测试驱动开发（Test Driven Development，TDD）之类实践的关键所在。
所以，主要的问题在于：代码的作者是否希望自己编写的组件能够脱离自己的控制、被使用在另一个应用程序中。如果答案是肯定的，那么他就不能对服务定位器做任何假设——哪怕最小的假设也会给使用者带来麻烦。

构造器注入 vs 属性注入

在组合服务时，你总得遵循一定的约定，才可能将所有东西拼装起来。依赖注入的优点主要在于：它只需要非常简单的约定——至少对于构造子注入和设值方法注入来说是这样。相比于这两者，接口注入的侵略性要强得多，比起Service Locator 模式的优势也不那么明显。
所以，如果你想要提供一个组件给多个使用者，构造子注入和设值方法注入看起来很有吸引力：你不必在组件中加入什么希奇古怪的东西，注入器可以相当轻松地把所有东西配置起来。
设值函数注入和构造子注入之间的选择相当有趣，因为它折射出面向对象编程的一些更普遍的问题：应该在哪里填充对象的字段，构造子还是设值方法？
一直以来，我首选的做法是尽量在构造阶段就创建完整、合法的对象——也就是说，在构造子中填充对象字段。这样做的好处可以追溯到 Kent Beck 在Smalltalk Best Practice Patterns 一书中介绍的两个模式：Constructor Method 和 Constructor Parameter Method。带有参数的构造子可以明确地告诉你如何创建一个合法的对象。如果创建合法对象的方式不止一种，你还可以提供多个构造子，以说明不同的组合方式。
构造子初始化的另一个好处是：你可以隐藏任何不可变的字段——只要不为它提供设值方法就行了。我认为这很重要：如果某个字段是不应该被改变的，“没有针对该字段的设值方法”就很清楚地说明了这一点。如果你通过设值方法完成初始化，暴露出来的设值方法很可能成为你心头永远的痛。（实际上，在这种时候我更愿意回避通常的设值方法约定，而是使用诸如initFoo 之类的方法名，以表明该方法只应该在对象创建之初调用。）
不过，世事总有例外。如果参数太多，构造子会显得凌乱不堪，特别是对于不支持关键字参数的语言更是如此。的确，如果构造子参数列表太长，通常标志着对象太过繁忙，理应将其拆分成几个对象，但有些时候也确实需要那么多的参数。
如果有不止一种的方式可以构造一个合法的对象，也很难通过构造子描述这一信息，因为构造子之间只能通过参数的个数和类型加以区分。这就是 Factory Method 模式适用的场合了，工厂方法可以借助多个私有构造子和设值方法的组合来完成自己的任务。经典 Factory Method 模式的问题在于：它们往往以静态方法的形式出现，你无法在接口中声明它们。你可以创建一个工厂类，但那又变成另一个服务实体了。“工厂服务”是一种不错的技巧，但你仍然需要以某种方式实例化这个工厂对象，问题仍然没有解决。
如果要传入的参数是像字符串这样的简单类型，构造子注入也会带来一些麻烦。使用设值方法注入时，你可以在每个设值方法的名字中说明参数的用途；而使用构造子注入时，你只能靠参数的位置来决定每个参数的作用，而记住参数的正确位置显然要困难得多。
如果对象有多个构造子，对象之间又存在继承关系，事情就会变得特别讨厌。为了让所有东西都正确地初始化，你必须将对子类构造子的调用转发给超类的构造子，然后处理自己的参数。这可能造成构造子规模的进一步膨胀。
尽管有这些缺陷，但我仍然建议你首先考虑构造子注入。不过，一旦前面提到的问题真的成了问题，你就应该准备转为使用设值方法注入。
在将 Dependecy Injection 模式作为框架的核心部分的几支团队之间，“构造子注入还是设值方法注入”引发了很多的争论。不过，现在看来，开发这些框架的大多数人都已经意识到：不管更喜欢哪种注入机制，同时为两者提供支持都是有必要的。

代码配置还是配置文件

另一个问题相对独立，但也经常与其他问题牵涉在一起：如何配置服务的组装，通过配置文件还是直接编码组装？对于大多数需要在多处部署的应用程序来说，一个单独的配置文件会更合适。配置文件几乎都是XML 文件，XML 也的确很适合这一用途。不过，有些时候直接在程序代码中实现装配会更简单。譬如一个简单的应用程序，也没有很多部署上的变化，这时用几句代码来配置就比XML 文件要清晰得多。
与之相对的，有时应用程序的组装非常复杂，涉及大量的条件步骤。一旦编程语言中的配置逻辑开始变得复杂，你就应该用一种合适的语言来描述配置信息，使程序逻辑变得更清晰。然后，你可以编写一个构造器（builder）类来完成装配工作。如果使用构造器的情景不止一种，你可以提供多个构造器类，然后通过一个简单的配置文件在它们之间选择。
我常常发现，人们太急于定义配置文件。编程语言通常会提供简捷而强大的配置管理机制，现代编程语言也可以将程序编译成小的模块，并将其插入大型系统中。如果编译过程会很费力，脚本语言也可以在这方面提供帮助。
通常认为，配置文件不应该用编程语言来编写，因为它们需要能够被不懂编程的系统管理人员编辑。但是，这种情况出现的几率有多大呢？我们真的希望不懂编程的系统管理人员来改变一个复杂的服务器端应用程序的事务隔离等级吗？只有在非常简单的时候，非编程语言的配置文件才有最好的效果。如果配置信息开始变得复杂，就应该考虑选择一种合适的编程语言来编写配置文件。
在Java世界里，我们听到了来自配置文件的不和谐音——每个组件都有它自己的配置文件，而且格式还各各不同。如果你要使用一打这样的组件，你就得维护一打的配置文件，那会很快让你烦死。
在这里，我的建议是：始终提供一种标准的配置方式，使程序员能够通过同一个编程接口轻松地完成配置工作。至于其他的配置文件，仅仅把它们当作一种可选的功能。借助这个编程接口，开发者可以轻松地管理配置文件。如果你编写了一个组件，则可以由组件的使用者来选择如何管理配置信息：使用你的编程接口、直接操作配置文件格式，或者定义他们自己的配置文件格式，并将其与你的编程接口相结合。

将配置从应用中分离

所有这一切的关键在于：服务的配置应该与使用分开。实际上，这是一个基本的设计原则——分离接口与实现。在面向对象程序里，我们在一个地方用条件逻辑来决定具体实例化哪一个类，以后的条件分支都由多态来实现，而不是继续重复前面的条件逻辑，这就是“分离接口与实现”的原则。

如果对于一段代码而言，接口与实现的分离还只是“有用”的话，那么当你需要使用外部元素（例如组件和服务）时，它就是生死攸关的大事。这里的第一个问题是：你是否希望将“选择具体实现类”的决策推迟到部署阶段。如果是，那么你需要使用插入技术。使用了插入技术之后，插件的装配原则上是与应用程序的其余部分分开的，这样你就可以轻松地针对不同的部署替换不同的配置。这种配置机制可以通过服务定位器来实现（Service Locator 模式），也可以借助依赖注入直接完成（Dependency Injection 模式）。