控制反轉 依賴注入
近來，Java 社區掀起一陣輕量級容器的熱潮，這些容器幫助開發者把不同項目的組件組合成一個內聚的應用程序。它們基於一個共同的模式，這個模式決定了容器如何組裝配件。開發人員給它取了一個非常抽象的名稱——"控制反轉"。在這篇文章里，我將挖掘這種模式的工作方式，並給它一個更加具體的名稱——"依賴注入"，同時也將比較它和服務定位器（可以替代控制反轉）的區別。在控制反轉和服務定位器之間進行選擇不是最重要的，應該將服務的配置和應用程序內部對服務的使用分離開，相比而言這點更為重要。
在 Java 世界的企業級應用中有一個有趣的現象：有很多人嘗試來研究主流 J2EE 技術的替代品，這大多出現在開源社區。它一方面很大程度地反映了，主流 J2EE 技術的笨重和復雜性，另一方面也產生了許多可選方案和許多擁有創意的想法。其中有一個共同的問題需要解決——如何組裝來自不同項目的程序模塊：例如多個團隊分別開發了各自的 Web 控制器和數據庫接口，這些程序之間的關聯非常少，你如何讓它們配合起來進行工作。很多框架都嘗試過去解決這個問題，其中一些分支還致力於提供一個通用的“組裝各層組件”的方案，這些框架通常被稱為輕量級容器，例如 PicoContainer 和 Spring 。
這些容器的構建，大都基於一些有趣的設計模式，不過這些模式已經超越了構建容器，甚至是實際 java 平台的范疇。這里，我將探索這些設計模式的奧秘。文中的例子我都是用 java 寫的，然而就像我寫過的其他原理性文章一樣，這些模式也同樣適用於其他面向對象的編程框架，特別是 .NET 框架。
組件和服務
討論“組裝程序元素”這個話題時，我們首先需要解決一個棘手的術語問題：如何區分“服務”（service）和“組件”（component）？你可以很容易地找到許多關於這兩個詞的長篇大論、彼此矛盾的定義。鑒於此，對於這兩個遭到了嚴重濫用的詞，我將首先說明它們在本文中的用法。
所謂“組件”是指這樣一個軟件單元：它將被某些應用程序使用，這些程序不受開發者的控制，也無法修改組件。或者這樣看，使用這個組件的應用程序不能修改組件的源代碼，但可以通過作者預留的某種途徑對其進行擴展以改變組件的行為。
服務與組件相似，它們都將被外部的應用程序使用。兩者之間最大的差異在於：組件是在本地使用（例如 JAR 文件、程序集、DLL、或者源碼導入）。而服務是要通過——同步或異步的——遠程接口來遠程使用的（例如 Web Service、消息系統、RPC，或者 socket）。
本文我將主要使用“服務”這個詞，但文中的大多數邏輯也同樣適用於本地組件。事實上，為了方便地訪問遠程服務，你往往需要某種本地組件框架。不過，使用“組件或者服務”這樣一個詞組實在太麻煩了，而且“服務”這個詞當下也很流行，所以本文將用“服務”指代這兩者。
一個簡單的示例
為了更好地說明問題，我會引入一個例子。與我之前使用的所有例子一樣，這是一個超級簡單的例子：它非常小，小到不夠真實，但足以幫助你看清其中的道理，而不至於陷入真實例子的泥潭。
在這個例子中，我編寫一個組件，用於提供一份由特定導演執導的電影清單。實現這個功能只需要一個方法：
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 類構造函數中。
MovieLister 類：
private MovieFinder finder; public MovieLister() { finder = new ColonDelimitedMovieFinder("movies1.txt"); }
ColonDelimitedMovieFinder 這個實現類的名字就說明，我將要從一個逗號分隔的文本文件中獲得影片列表。我不會給出該類的具體細節，畢竟這很簡單，你設想有這樣一個實現就行。
現在，如果這個類只是我自己使用，一切都沒有問題。但如果我的朋友嘆服於這個精彩的功能，也想使用我的程序，那又會怎樣呢？如果他們也想把影片清單保存在一個逗號分隔的文本文件中，並且也把這個文件命名為“movie.txt”，那么一切也沒問題。如果他們用完全不同的方式，例如 SQL 數據庫、XML 文件、Web Service，或是另一種格式的文本文件，來存儲影片清單呢？在這種情況下，我們需要用另一個類來獲取數據。由於已經定義了 MovieFinder 接口，我可以不用修改 moviesDirectedBy 方法。但我仍然需要通過某種途徑來獲得合適的 MovieFinder 接口的實例。
圖1：在 lister 類中使用一個簡單的構造器來創建依賴關系
圖 1 顯示了這種情況下的依賴關系。MovieLister 類既依賴於 MovieFinder 接口，也依賴於該接口的具體的實現類。我們當然希望 MovieLister 類僅僅依賴於接口，但又如何獲得一個 MovieFinder 子類的實例呢？
也就是說，MovieLister 類依賴於 MovieFinder 接口，還要在該類中實例化該接口，但我們如何做才能不在 MovieLister 類內實例化 MovieFinder 接口，讓這個類僅僅依賴與 MovieFinder 接口？
在 Patterns Of Enterprise Application Architecture 一書中，我們把這種情況稱為插件（Plugin）。MovieFinder 的實現類不是在編譯階段連入程序之中的，因為我並不知道我的朋友會使用哪個實現類。我們希望 MovieLister 類能夠與 MovieFinder 的任何實現類工作，並且允許在運行時插入具體的實現類，插入動作完全脫離我（原作者）的控制。問題是，如何設計這個連接過程，使 MovieLister 類在不知道實現類細節的前提下與其實例協同工作。
將這個例子推廣到真實的系統，我們可能有數十個這樣的服務和組件。在任何時候，我們總可以對組件的使用進行抽象，通過接口與具體的組件交流（如果組件沒有設計接口，也可以通過適配器與之交流）。但如果我們希望以不同的方式部署這個系統，就需要用插件機制來處理服務之間的交互過程，這樣我們才能在不同的部署方案中使用不同的實現。
所以，現在的核心問題是，如何將這些插件裝配到一個應用程序？這正是新生的輕量級容器所面臨的一個主要問題，而它們解決這個問題的手段無一例外地是控制反轉（Inversion Of Control）模式。
控制反轉
幾位輕量級容器的作者曾驕傲地對我說：這些容器非常有用，因為它們實現了控制反轉。這樣的說辭讓我深感迷惑：控制反轉是框架所共有的特征，如果僅僅因為使用了控制反轉就認為這些輕量級容器與眾不同，就好像在說我的轎車是與眾不同的，因為它有四個輪子。
問題的關鍵在於：它們反轉了哪方面的控制？我第一次接觸到的控制反轉是針對用戶界面的主控權。早期的用戶界面完全是由應用程序來控制的，你預先設計一系列命令，例如輸入姓名、輸入地址等，應用程序逐條輸出提示信息，並取回用戶的響應。而在圖形用戶界面環境下，UI 框架將負責執行一個主循環，你的應用程序只需為屏幕的各個區域提供事件處理函數即可。在這里，程序的控制權發生了反轉：從應用程序轉移到了框架。
對於這些新生的容器，它們反轉的是如何查找插件的具體實現。在前面的例子中，MovieLister 類直接實例化 MovieFinder。這樣，MovieFinder 也就不成其為插件了，因為它不是在運行時插入應用程序中的。而這些輕量級容器則使用了更為靈活的方法，只要插件遵循一定的規則，一個獨立的組件模塊就能夠將插件的具體實現注入到應用程序中。
因此，我想我們需要給這個模式起一個更能說明其特點的名字——“控制反轉”，這個名字太寬泛了，常常讓人有些迷惑。與多位 IoC 愛好者討論后，我們決定將這個模式叫做“依賴注入”（Dependency Injection）。
下面，我將開始介紹 Dependency Injection 的幾種不同形式。不過，在此之前，我要先指出，要消除應用程序對插件實現的依賴，依賴注入並不是唯一的選擇，你也可以用 Service Locator 模式獲得同樣的效果。介紹完 Dependency Injection 模式之后，我會談到 Service Locator 模式。
依賴注入模式
Dependency Injection 模式的基本思想是，用一個單獨的對象（裝配器）來獲得 MovieFinder 的一個合適的實現，並將其實例賦給 MovieLister 類的一個字段。這樣，我們就得到了圖 2 所示的依賴圖。
圖2：一個依賴注入器的依賴關系
依賴注入的形式主要有三種，我們分別將它們叫做構造函數注入（Constructor Injection）、設置方法注入（Setter Injection）和接口注入（Interface Injection）。如果讀過最近關於 IoC 的一些討論材料，你不難看出，這三種方法分別就是 type 1 IoC（接口注入）、type 2 IoC（設置方法注入）和 type 3 IoC（構造函數注入）。我發現數字編號往往比較難記，所以我使用了這里的命名方式。
使用 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 類對具體 MovieFinder 實現類的依賴。這樣，我就可以把 MovieLister 類交給朋友，讓他們根據自己環境插入一個合適的 MovieFinder 實現即可。不過，Dependency Injection 模式並不是打破這層依賴關系的唯一手段，另一種方法是使用 Service Locator 模式。
Service Locator 模式背后的基本思想是，有一個對象（即服務定位器）知道如何獲得一個應用程序所需的所有服務。也就是說，在我們的例子中，服務定位器應該有一個方法，用於獲取一個 MovieFinder 實例。當然，這不過是把麻煩換了一個樣子而已，我們任然必須在 MovieLister 中獲得服務定位器，最終得到的依賴關系如圖 3 所示：
在這里，我把 ServiceLocator 類實現為一個 Singleton 的注冊表，於是 MovieLister 就可以在實例化時通過 Service Locator 獲得一個 MovieFinder 實例。
圖3：服務定位器的依賴關系
與注入方式一樣，我們也必須對服務定位器加以配置。這里，我直接在代碼中進行配置，但設計一種通過配置文件獲得數據的機制也並非難事。
MovieLister 類：
MovieFinder finder = ServiceLocator.movieFinder();
ServiceLocator 類：
public static MovieFinder movieFinder() { return soleInstance.movieFinder; } private static ServiceLocator soleInstance; private MovieFinder movieFinder;
與注入的方法一樣，我們必須配置服務定位器。在這里，我在代碼中這樣做，但它並不難使用一個機制，從配置文件讀取適當的數據。
Tester 類：
private void configure() { ServiceLocator.load(new ServiceLocator(new ColonMovieFinder("movies1.txt"))); }
ServiceLocator 類：
public static void load(ServiceLocator arg) { soleInstance = arg; } public ServiceLocator(MovieFinder movieFinder) { this.movieFinder = movieFinder; }
下面是測試代碼：
Tester 類：
public void testSimple() { configure(); MovieLister lister = new MovieLister(); Movie[] movies = lister.moviesDirectedBy("Sergio Leone"); assertEquals("Once Upon a Time in the West", movies[0].getTitle()); }
我時常聽到這樣的論調：這樣的服務定位器不是什么好東西，因為你無法替換它返回的服務實現，從而導致無法對它們進行測試。當然，如果你的設計很糟糕，你的確會遇到這樣的麻煩；但你也可以選擇良好的設計。在這個例子中，ServiceLocator 實例僅僅是一個簡單的數據容器，只需要對它做一些簡單的修改，就可以讓他返回用於測試的服務實現。
對於更復雜的情況，我可以從 ServiceLocator 派生出多個子類，並將子類的實例傳遞給注冊表的類變量。另外，我可以修改 ServiceLocator 的靜態方法，使其調用 ServiceLocator 實例的方法，而不是直接訪問實例變量。我還可以使用特定於線程的存儲機制，從而提供特定於線程的服務定位器。所有這一切改進都無需修改 ServiceLocator 的使用者。
一個改進的思路是，服務定位器仍然是一個注冊表，但不是 Singleton。Singleton 的確是實現注冊表的一種簡單途徑，但這只是一個實現時的決定，可以很輕松地改變它。
為服務定位器使用分離接口
上面這種簡單的實現方式有一個問題，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 實例，並將后者保存起來。
選擇使用哪個
到現在為止，我一直在闡述自己對這兩個模式（Dependency Injection 模式和 Service Locator 模式）以及它們的變化形式的看法。現在，我要開始討論他們的優點和缺點，以便指出它們各自適用的場景。
服務定位 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 模式）。
其他問題
在本文中，我關注的焦點是使用 Dependency Injection 模式和 Service Locator 模式進行服務配置的基本問題。還有一些與之相關的話題值得關注，但我已經沒有時間繼續申發下去了。特別值得注意的是生命周期行為的問題：某些組件具有特定的生命周期事件，例如“停止”、“開始”等等。另一個值得注意的問題是：越來越多的人對“如何在這些容器中運用面向方面（aspect oriented）的思想”產生了興趣。盡管目前還沒有認真准備過這方面的材料，但我也很希望以后能在這個話題上寫一些東西。
關於這些問題，你在專注於輕量級容器的網站上可以找到很多資料。瀏覽與 PicoContainer 或者 Spring 相關的網站，你可以找到大量相關的討論，並由此引申出更多的話題。
結論和思考
在時下流行的輕量級容器都使用了一個共同的模式來組裝應用程序所需的服務，我把這個模式稱為 Dependency Injection，它可以有效地替代 Service Locator 模式。在開發應用程序時，兩者不相上下，但我認為 Service Locator 模式略有優勢，因為它的行為方式更為直觀。但是，如果你開發的組件要交給多個應用程序去使用，那么 Dependency Injection 模式會是更好的選擇。
如果你決定使用 Dependency Injection 模式，這里還有幾種不同的風格可供選擇。我建議你首先考慮構造子注入；如果遇到了某些特定的問題，再改用設值方法注入。如果你要選擇一個容器，在其之上進行開發，我建議你選擇同時支持這兩種注入方式的容器。
Service Locator 模式和 Dependency Injection 模式之間的選擇並不是最重要的，更重要的是：應該將服務的配置和應用程序內部對服務的使用分離開。
查找更多相關的主題
請查看下面的標簽：
感謝
真誠地感謝為本文發布提供過幫助的人！Rod Johnson，Paul Hammant，Joe Walnes，Aslak HellesøY，Jon TirséN 和 Bill Caputo 在本文早期草稿的評論中提供了許多相關的概念。Berin Loritsch 和漢密爾頓瑞西蒙德奧利維拉提供了一些非常有用的建議。Dave W Smith 指出了最初接口的依賴注入配置的代碼問題。Gerry Lowry 幫我修復了很多錯誤。感謝你們！
修訂版本
2004-1-23: 重寫接口依賴注入例子中的配置文件代碼
2004-1-16: 為 Avalon 的定位器和依賴注入添加一個簡單的例子
2004-1-14: 發布第一版
譯文參考網站：
http://www.cnblogs.com/liuning8023/p/di.html
http://www.cnblogs.com/me-sa/archive/2008/07/30/iocdi.html
原文地址（英文）：