反转控制容器与依赖注入模式中英文翻译资料.doc

反转控制容器与依赖注入模式 在企业级Java 的世界里存在一个有趣的现象：有很多人投入很多精力来研究主流J2EE 技术的替代品——自然，这大多发生在open source 社群。在很大程度上，这可以看作是开发者对主流J2EE 技术的笨重和复杂作出的回应，但其中的确有很多极富创意的想法，的确提供了一些可供选择的方案。J2EE 开发者常遇到的一个问题就是如何组装不同的程序元素：如果web 控制器体系结构和数据库接口是由不同的团队所开发的，彼此几乎一无所知，你应该如何让它们配合工作？很多框架尝试过解决这个问题，有几个框架索性朝这个方向发展，提供了更通用的组装各层组件的方案。这样的框架通常被称为轻量级容器，PicoContainer 和Spring 都在此列。在这些容器背后，一些有趣的设计原则发挥着作用。这些原则已经超越了特定容器的，甚至已经超越了Java 平台的范畴。在本文中，我就要初步揭示这些原则。我使用的范例是Java 代码，但正如我的大多数文章一样，这些原则也同样适用于的OO 环境，特别是.NET。这样的话题立即将我拖进了一个棘手的术语问题：如何区分服务（service）和组件（component）？你可以毫不费力地找出关于这两个词定义的长篇大论。有鉴于此，对于这两个遭到了严重滥用的词汇，我将首先说明它们在本文中的用法。它将被作者无法控制的其他应用程序使用，但后者不能对组件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但可以通过作者预留的某种途径对其进行扩展，以改变组件的行为。在本文中，我将主要使用服务这个词，但文中的大多数逻辑也同样适用于本地组件。实际上，为了方便地访问远程服务，你往往需要某种本地组件框架。不过，组件或者服务这样一个词组实在太麻烦了，而且服务这个词当下也很流行，所以本文将用服务指代这两者。为了更好地说明问题，我要引入一个例子。和我以前用的所有例子一样，这是一个超级简单的例子：它非常小，小得有点不够真实，但足以帮助你看清其中的道理，而不至于陷入真实例子的泥潭中无法自拔。在这个例子中，我编写了一个组件，用于提供一份电影清单，清单上列出的影片都是由一位特定的导演执导的。实现这个伟大的功能只需要一个方法：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()]); } 这个功能的实现极其简单：moviesDirectedBy 方法首先请求finder（影片搜寻者）对象（我们稍后会谈到这个对象）返回后者所知道的所有影片，然后遍历finder 对象返回的清单，并返回其中由特定的某个导演执导的影片。非常简单，不过不必担心，这只是整个例子的脚手架罢了。我们真正想要考察的是finder对象，或者说，如何将MovieLister对象与特定的finder对象连接起来。为什么我们对这个问题特别感兴趣？因为我希望上面这个漂亮的moviesDirectedBy方法完全不依赖于影片的实际存储方式。所以，这个方法只能引用一个finder对象，而finder对象则必须知道如何对findAll 方法作出回应。为了帮助读者更清楚地理解，我给finder定义了一个接口：public interface MovieFinder { List findAll(); } 现在，两个对象之间没有耦合关系。但是，当我要实际寻找影片时，就必须涉及到MovieFinder 的某个具体子类。在这里，我把”涉及具体子类”的代码放在MovieLister 类的构造class MovieLister... private MovieFinder finder; public MovieLister() { finder = new ColonDelimitedMovieFinder(movies1.txt); } 这个实现类的名字就说明：我将要从一个逗号分隔的文本文件中获得影片列表。你不必操心具体的实现细节，只要设想这样一个实现类就可以了。如果这个类只由我自