控制反转和依赖注入.doc

控制反转和依赖注入 IoC 容器和 Dependency Injection 模式 撰文/Martin Fowler 编译/透明 Java 社群近来掀起了一阵轻量级容器的热潮，这些容器能够帮助开发者将来自不同项目的组件 组装成为一个内聚的应用程序。在它们的背后有着同一个模式，这个模式决定了这些容器进行组 件装配的方式。人们用一个大而化之的名字来称呼这个模式：“控制反转”（Inversion of Control，IoC）。在本文中，我将深入探索这个模式的工作原理，给它一个更能描述其特点的名 字—— “依赖注入”（Dependency Injection），并将其与“服务定位器”（Service Locator ） 模式作一个比较。不过，这两者之间的差异并不太重要，更重要的是：应该将组件的配置与使用 分离开——两个模式的目标都是这个。 在企业级Java 的世界里存在一个有趣的现象：有很多人投入很多精力来研究主流J2EE 技术的 替代品——自然，这大多发生在open source 社群。在很大程度上，这可以看作是开发者对主 流J2EE 技术的笨重和复杂作出的回应，但其中的确有很多极富创意的想法，的确提供了一些可 供选择的方案。J2EE 开发者常遇到的一个问题就是如何组装不同的程序元素：如果 web 控制 器体系结构和数据库接口是由不同的团队所开发的，彼此几乎一无所知，你应该如何让它们配合 工作？很多框架尝试过解决这个问题，有几个框架索性朝这个方向发展，提供了更通用的“组装 各层组件”的方案。这样的框架通常被称为“轻量级容器”，PicoContainer和 Spring 都在此 列中。 在这些容器背后，一些有趣的设计原则发挥着作用。这些原则已经超越了特定容器的范畴，甚至 已经超越了Java 平台的范畴。在本文中，我就要初步揭示这些原则。我使用的范例是 Java 代 码，但正如我的大多数文章一样，这些原则也同样适用于别的OO 环境，特别是.NET。 组件和服务 “装配程序元素”，这样的话题立即将我拖进了一个棘手的术语问题：如何区分“服务”（service） 和“组件”（component ）？你可以毫不费力地找出关于这两个词定义的长篇大论，各种彼此 矛盾的定义会让你感受到我所处的窘境。有鉴于此，对于这两个遭到了严重滥用的词汇，我将首 先说明它们在本文中的用法。 所谓“组件”是指这样一个软件单元：它将被作者无法控制的其他应用程序使用，但后者不能对 组件进行修改。也就是说，使用一个组件的应用程序不能修改组件的源代码，但可以通过作者预 留的某种途径对其进行扩展，以改变组件的行为。 服务和组件有某种相似之处：它们都将被外部的应用程序使用。在我看来，两者之间最大的差异 在于：组件是在本地使用的（例如JAR 文件、程序集、DLL、或者源码导入）；而服务是要通过 ——同步或异步的——远程接口来远程使用的（例如 web service、消息系统、RPC，或者 socket ）。 在本文中，我将主要使用“服务”这个词，但文中的大多数逻辑也同样适用于本地组件。实际上， 为了方便地访问远程服务，你往往需要某种本地组件框架。不过，“组件或者服务”这样一个词 组实在太麻烦了，而且“服务”这个词当下也很流行，所以本文将用“服务”指代这两者。 一个简单的例子 为了更好地说明问题，我要引入一个例子。和我以前用的所有例子一样，这是一个超级简单的例 子：它非常小，小得有点不够真实，但足以帮助你看清其中的道理，而不至于陷入真实例子的泥 潭中无法自拔。 在这个例子中，我编写了一个组件，用于提供一份电影清单，清单上列出的影片都是由一位特定 的导演执导的。实现这个伟大的功能只需要一个方法： 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()]); } 你可以看到，这个功能的实现