控制反轉和依賴注入模式

Java社羣近來掀起了一陣輕量級容器的熱潮，這些容器能夠幫助開發者將來自不同項目的組件組裝成爲一個內聚的應用程序。在它們的背後有着同一個模式，這個模式決定了這些容器進行組件裝配的方式。人們用一個大而化之的名字來稱呼這個模式：“控制反轉”（ Inversion of Control，IoC）。在本文中，我將深入探索這個模式的工作原理，給它一個更能描述其特點的名字——“依賴注入”（Dependency Injection），並將其與“服務定位器”（Service Locator）模式作一個比較。不過，這兩者之間的差異並不太重要，更重要的是：應該將組件的配置與使用分離開——兩個模式的目標都是這個。

在企業級Java的世界裏存在一個有趣的現象：有很多人投入很多精力來研究主流J2EE 技術的替代品——自然，這大多發生在open source社羣。在很大程度上，這可以看作是開發者對主流J2EE技術的笨重和複雜作出的迴應，但其中的確有很多極富創意的想法，的確提供了一些可供選擇的方案。J2EE開發者常遇到的一個問題就是如何組裝不同的程序元素：如果web控制器體系結構和數據庫接口是由不同的團隊所開發的，彼此幾乎一無所知，你應該如何讓它們配合工作？很多框架嘗試過解決這個問題，有幾個框架索性朝這個方向發展，提供了更通用的“組裝各層組件”的方案。這樣的框架通常被稱爲“輕量級容器”，PicoContainer和Spring都在此列中。

在這些容器背後，一些有趣的設計原則發揮着作用。這些原則已經超越了特定容器的範疇，甚至已經超越了Java平臺的範疇。在本文中，我就要初步揭示這些原則。我使用的範例是Java代碼，但正如我的大多數文章一樣，這些原則也同樣適用於別的面向對象的環境，特別是.NET。

組件和服務

裝配程序元素，這樣的話題立即將我拖進了一個棘手的術語問題：如何區分“服務”（service）和“組件”（component）？你可以毫不費力地找出關於這兩個詞定義的長篇大論，各種彼此矛盾的定義會讓你感受到我所處的窘境。有鑑於此，對於這兩個遭到了嚴重濫用的詞彙，我將首先說明它們在本文中的用法。

所謂“組件”是指這樣一個軟件單元：它將被作者無法控制的其他應用程序使用，但後者不能對組件進行修改。也就是說，使用一個組件的應用程序不能修改組件的源代碼，但可以通過作者預留的某種途徑對其進行擴展，以改變組件的行爲。

服務和組件有某種相似之處：它們都將被外部的應用程序使用。在我看來，兩者之間最大的差異在於：組件是在本地使用的（例如JAR文件、程序集、DLL、或者源碼導入）；而服務是要通過同步或異步的遠程接口來遠程使用的（例如web service、消息系統、RPC，或者socket）。

在本文中，我將主要使用“服務”這個詞，但文中的大多數邏輯也同樣適用於本地組件。實際上，爲了方便地訪問遠程服務，你往往需要某種本地組件框架。不過，“組件或者服務”這樣一個詞組實在太麻煩了，而且“服務”這個詞當下也很流行，所以本文將用“服務”指代這兩者。

一個簡單的例子

爲了更好地說明問題，我要引入一個例子。和我以前用的所有例子一樣，這是一個超級簡單的例子：它非常小，小得有點不夠真實，但足以幫助你看清其中的道理，而不至於陷入真實例子的泥潭中無法自拔。

在這個例子中，我編寫了一個組件，用於提供一份電影清單，清單上列出的影片都是由一位特定的導演執導的。實現這個偉大的功能只需要一個方法：

1

class MovieLister...

2

    public Movie[]
moviesDirectedBy(String arg) {

3

        List
allMovies = finder.findAll();

4

        for (Iterator
it = allMovies.iterator(); it.hasNext();) {

5

            Movie
movie = (Movie) it.next();

6

            if (!movie.getDirector().equals(arg))
it.remove();

7

        }

8

        return (Movie[])
allMovies.toArray(new Movie[allMovies.size()]);

9

    }

你可以看到，這個功能的實現極其簡單：moviesDirectedBy方法首先請求finder（影片搜尋者）對象（我們稍後會談到這個對象）返回後者所知道的所有影片，然後遍歷finder對象返回的清單，並返回其中由特定的某個導演執導的影片。非常簡單，不過不必擔心，這只是整個例子的腳手架罷了。

我們真正想要考察的是finder對象，或者說，如何將MovieLister對象與特定的finder對象連接起來。爲什麼我們對這個問題特別感興趣？因爲我希望上面這個漂亮的moviesDirectedBy方法完全不依賴於影片的實際存儲方式。所以，這個方法只能引用一個finder對象，而finder對象則必須知道如何對findAll 方法作出迴應。爲了幫助讀者更清楚地理解，我給finder定義了一個接口：

1

public interface MovieFinder
{

2

    List
findAll();

3

}

現在，兩個對象之間沒有什麼耦合關係。但是，當我要實際尋找影片時，就必須涉及到MovieFinder的某個具體子類。在這裏，我把涉及具體子類的代碼放在MovieLister類的構造函數中。

1

class MovieLister...

2

  private MovieFinder
finder;

3

  public MovieLister()
{

4

    finder
= new ColonDelimitedMovieFinder("movies1.txt");

5

  }

這個實現類的名字就說明：我將要從一個逗號分隔的文本文件中獲得影片列表。你不必操心具體的實現細節，只要設想這樣一個實現類就可以了。

如果這個類只由我自己使用，一切都沒問題。但是，如果我的朋友歎服於這個精彩的功能，也想使用我的程序，那又會怎麼樣呢？如果他們也把影片清單保存在一個逗號分隔的文本文件中，並且也把這個文件命名爲“ movie1.txt ”，那麼一切還是沒問題。如果他們只是給這個文件改改名，我也可以從一個配置文件獲得文件名，這也很容易。但是，如果他們用完全不同的方式——例如SQL 數據庫、XML 文件、web service，或者另一種格式的文本文件——來存儲影片清單呢？在這種情況下，我們需要用另一個類來獲取數據。由於已經定義了MovieFinder接口，我可以不用修改moviesDirectedBy方法。但是，我仍然需要通過某種途徑獲得合適的MovieFinder實現類的實例。

圖1展現了這種情況下的依賴關係：MovieLister類既依賴於MovieFinder接口，也依賴於具體的實現類。我們當然希望MovieLister類只依賴於接口，但我們要如何獲得一個MovieFinder子類的實例呢？

在 P of EAA（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類必須聲明一個構造函數，並在其中包含所有需要注入的元素：

1

class MovieLister...

2

    public MovieLister(MovieFinder
finder) {

3

        this.finder
= finder;      

4

    }

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

1

class ColonMovieFinder...

2

    public ColonMovieFinder(String
filename) {

3

        this.filename
= filename;

4

    }

隨後，需要告訴PicoContainer：各個接口分別與哪個實現類關聯、將哪個字符串注入MovieFinder組件。

1

private MutablePicoContainer
configureContainer() {

2

    MutablePicoContainer
pico = new DefaultPicoContainer();

3

    Parameter[]
finderParams =  {new ConstantParameter("movies1.txt")};

4

    pico.registerComponentImplementation(MovieFinder.class,
ColonMovieFinder.class,
finderParams);

5

    pico.registerComponentImplementation(MovieLister.class);

6

    return pico;

7

}

這段配置代碼通常位於另一個類。對於我們這個例子，使用我的MovieLister 類的朋友需要在自己的設置類中編寫合適的配置代碼。當然，還可以將這些配置信息放在一個單獨的配置文件中，這也是一種常見的做法。你可以編寫一個類來讀取配置文件，然後對容器進行合適的設置。儘管PicoContainer本身並不包含這項功能，但另一個與它關係緊密的項目NanoContainer提供了一些包裝，允許開發者使用XML配置文件保存配置信息。NanoContainer能夠解析XML文件，並對底下的PicoContainer進行配置。這個項目的哲學觀念就是：將配置文件的格式與底下的配置機制分離開。

使用這個容器，你寫出的代碼大概會是這樣：

1

public void testWithPico()
{

2

        MutablePicoContainer
pico = configureContainer();

3

        MovieLister
lister = (MovieLister) pico.getComponentInstance(MovieLister.class);

4

        Movie[]
movies = lister.moviesDirectedBy("Sergio
Leone");

5

        assertEquals("Once
Upon a Time in the West",
movies[0].getTitle());

6

    }

儘管在這裏我使用了構造函數注入，實際上PicoContainer也支持設值方法注入，不過該項目的開發者更推薦使用構造函數注入。

使用Spring 進行設值方法注入

Spring 框架是一個用途廣泛的企業級Java 開發框架，其中包括了針對事務、持久化框架、web應用開發和JDBC等常用功能的抽象。和PicoContainer一樣，它也同時支持構造函數注入和設值方法注入，但該項目的開發者更推薦使用設值方法注入——恰好適合這個例子。

爲了讓MovieLister類接受注入，我需要爲它定義一個設值方法，該方法接受類型爲MovieFinder的參數：

1

class MovieLister...

2

    private MovieFinder
finder;

3

  public void setFinder(MovieFinder
finder) {

4

    this.finder
= finder;

5

  }

類似地，在MovieFinder的實現類中，我也定義了一個設值方法，接受類型爲String 的參數：

1

class ColonMovieFinder...

2

    public void setFilename(String
filename) {

3

        this.filename
= filename;

4

    }

第三步是設定配置文件。Spring 支持多種配置方式，你可以通過XML 文件進行配置，也可以直接在代碼中配置。不過，XML 文件是比較理想的配置方式。

01

<beans>

02

        <bean
id="MovieLister" class="spring.MovieLister">

03

            <property
name="finder">

04

                <ref
local="MovieFinder"/>

05

            </property>

06

        </bean>

07

        <bean
id="MovieFinder" class="spring.ColonMovieFinder">

08

            <property
name="filename">

09

                <value>movies1.txt</value>

10

            </property>

11

        </bean>

12

    </beans>

於是，測試代碼大概就像下面這樣：

1

public void testWithSpring() throws Exception
{

2

    ApplicationContext
ctx = new FileSystemXmlApplicationContext("spring.xml");

3

    MovieLister
lister = (MovieLister) ctx.getBean("MovieLister");

4

    Movie[]
movies = lister.moviesDirectedBy("Sergio
Leone");

5

    assertEquals("Once
Upon a Time in the West",
movies[0].getTitle());

6

}

接口注入

除了前面兩種注入技術，還可以在接口中定義需要注入的信息，並通過接口完成注入。Avalon框架就使用了類似的技術。在這裏，我首先用簡單的範例代碼說明它的用法，後面還會有更深入的討論。

首先，我需要定義一個接口，組件的注入將通過這個接口進行。在本例中，這個接口的用途是將一個MovieFinder實例注入繼承了該接口的對象。

1

public interface InjectFinder
{

2

    void injectFinder(MovieFinder
finder);

3

}

這個接口應該由提供MovieFinder接口的人一併提供。任何想要使用MovieFinder實例的類（例如MovieLister類）都必須實現這個接口。

1

class MovieLister implements InjectFinder...

2

    public void injectFinder(MovieFinder
finder) {

3

        this.finder
= finder;

4

    }

然後，我使用類似的方法將文件名注入MovieFinder的實現類：

1

public interface InjectFinderFilename
{

2

    void injectFilename
(String filename);

3

}

1

class ColonMovieFinder implements MovieFinder,
InjectFinderFilename......

2

    public void injectFilename(String
filename) {

3

        this.filename
= filename;

4

    }

然後，還需要用一些配置代碼將所有的組件實現裝配起來。簡單起見，我直接在代碼中完成配置，並將配置好的MovieLister 對象保存在名爲lister的字段中：

1

class Tester...

2

    private Container
container;

3

4

     private void configureContainer()
{

5

       container
= new Container();

6

       registerComponents();

7

       registerInjectors();

8

       container.start();

9

    }

配置的工作分兩步，通過查找鍵值註冊組件，同其他示例非常類似。

1

class Tester...

2

  private void registerComponents()
{

3

    container.registerComponent("MovieLister",
MovieLister.class);

4

    container.registerComponent("MovieFinder",
ColonMovieFinder.class);

5

  }

新的一個註冊注入器的步驟是註冊依賴的組件。每一個注入接口需要一些用來注入依賴對象的代碼。這裏我通過使用容器的註冊注入器對象來實現。每一個注入器對象實現了注入器接口。

class 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);

}

當依賴是一個爲這個容易編寫的類時，爲這個組件實現注入器接口本身是有意義的，就像我在movie finder中所做的那樣。對於一般的類，例如字符串，我在一段配置代碼中使用了內部類。

class ColonMovieFinder implements Injector......
  public void inject(Object target) {
    ((InjectFinder) target).injectFinder(this);        
  }

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

讓後再測試中使用這個容器。

class 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());
    }

容器使用了聲明的注入器接口來計算出依賴，並且注入器注入了正確的依賴。（具體的容器實現在這裏並不是什麼重要的技術，這裏我不做展示。）

使用Service Locator

依賴注入的最大好處在於：它消除了MovieLister類對具體MovieFinder實現類的依賴。這樣一來，我就可以把MovieLister類交給朋友，讓他們根據自己的環境插入一個合適的MovieFinder實現即可。不過，Dependency Injection模式並不是打破這層依賴關係的唯一手段，另一種方法是使用Service Locator模式。
Service Locator模式背後的基本思想是：有一個對象（即服務定位器）知道如何獲得一個應用程序所需的所有服務。也就是說，在我們的例子中，服務定位器應該有一個方法，用於獲得一個MovieFinder實例。當然，這不過是把麻煩換了一個樣子，我們仍然必須在MovieLister中獲得服務定位器，最終得到的依賴關係如圖3 所示：

圖3：使用Service Locator 模式之後的依賴關係

在這裏，我把ServiceLocator類實現爲一個Singleton的註冊表，於是MovieLister就可以在實例化時通過ServiceLocator獲得一個MovieFinder實例。

1

class MovieLister...

2

    MovieFinder
finder = ServiceLocator.movieFinder();

1

class ServiceLocator...

2

    public static MovieFinder
movieFinder() {

3

        return soleInstance.movieFinder;

4

    }

5

    private static ServiceLocator
soleInstance;

6

    private MovieFinder
movieFinder;

和注入的方式一樣，我們也必須對服務定位器加以配置。在這裏，我直接在代碼中進行配置，但設計一種通過配置文件獲得數據的機制也並非難事。

1

class Tester...

2

    private void configure()
{

3

        ServiceLocator.load(new ServiceLocator(new ColonMovieFinder("movies1.txt")));

4

    }

1

class ServiceLocator...

2

    public static void load(ServiceLocator
arg) {

3

        soleInstance
= arg;

4

    }

5

6

    public ServiceLocator(MovieFinder
movieFinder) {

7

        this.movieFinder
= movieFinder;

8

    }

下面是測試代碼：

1

class Tester...

2

    public void testSimple()
{

3

        configure();

4

        MovieLister
lister = new MovieLister();

5

        Movie[]
movies = lister.moviesDirectedBy("Sergio
Leone");

6

        assertEquals("Once
Upon a Time in the West",
movies[0].getTitle());

7

    }

我時常聽到這樣的論調：這樣的服務定位器不是什麼好東西，因爲你無法替換它返回的服務實現，從而導致無法對它們進行測試。當然，如果你的設計很糟糕，你的確會遇到這樣的麻煩；但你也可以選擇良好的設計。在這個例子中，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還提供了一個通用的方法，用於獲取和加載服務對象。

01

class ServiceLocator...

02

    private static ServiceLocator
soleInstance;

03

    public static void load(ServiceLocator
arg) {

04

        soleInstance
= arg;

05

    }

06

    private Map
services = new HashMap();

07

    public static Object
getService(String key){

08

        return soleInstance.services.get(key);

09

    }

10

    public void loadService
(String key, Object service) {

11

        services.put(key,
service);

12

    }

同樣需要對服務定位器進行配置，將服務對象與適當的關鍵字加載到定位器中：

1

class Tester...

2

    private void configure()
{

3

        ServiceLocator
locator = new ServiceLocator();

4

        locator.loadService("MovieFinder", new ColonMovieFinder("movies1.txt"));

5

        ServiceLocator.load(locator);

6

    }

我使用與服務對象類名稱相同的字符串作爲服務對象的關鍵字：

1

class MovieLister...

2

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

總體而言，我不喜歡這種方式。無疑，這樣實現的服務定位器具有更強的靈活性，但它的使用方式不夠直觀明朗。我只有通過文本形式的關鍵字才能找到一個服務對象。相比之下，我更欣賞通過一個方法明確獲得服務對象的方式，因爲這讓使用者能夠從接口定義中清楚地知道如何獲得某項服務。

使用兼顧服務定位器和依賴注入

Dependency Injection和Service Locator兩個模式並不是互斥的，你可以同時使用它們，Avalon框架就是這樣的一個例子。Avalon使用了服務定位器，但如何獲得定位器的信息則是通過注入的方式告知組件的。

對於前面一直使用的例子，Berin Loritsch發送給了我一個簡單的Avalon實現版本：

1

public class MyMovieLister implements MovieLister,
Serviceable {

2

    private MovieFinder
finder;

3

4

    public void service(
ServiceManager manager ) throws ServiceException
{

5

        finder
= (MovieFinder)manager.lookup("finder");

6

    }

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 模式作爲框架的核心部分的幾支團隊之間，構造函數注入還是設值方法注入引發了很多的爭論。不過，現在看來，開發這些框架的大多數人都已經意識到：不管更喜歡哪種注入機制，同時爲兩者提供支持都是有必要的。

代碼配置or配置文件

另一個問題相對獨立，但也經常與其他問題牽涉在一起：如何配置服務的組裝，通過配置文件還是直接編碼組裝？對於大多數需要在多處部署的應用程序來說，一個單獨的配置文件會更合適。配置文件幾乎都是XML 文件，XML 也的確很適合這一用途。不過，有些時候直接在程序代碼中實現裝配會更簡單。譬如一個簡單的應用程序，也沒有很多部署上的變化，這時用幾句代碼來配置就比XML 文件要清晰得多。

與之相對的，有時應用程序的組裝非常複雜，涉及大量的條件步驟。一旦編程語言中的配置邏輯開始變得複雜，你就應該用一種合適的語言來描述配置信息，使程序邏輯變得更清晰。然後，你可以編寫一個構造器（builder）類來完成裝配工作。如果使用構造器的情景不止一種，你可以提供多個構造器類，然後通過一個簡單的配置文件在它們之間選擇。

我常常發現，人們太急於定義配置文件。編程語言通常會提供簡捷而強大的配置管理機制，現代編程語言也可以將程序編譯成小的模塊，並將其插入大型系統中。如果編譯過程會很費力，腳本語言也可以在這方面提供幫助。

通常認爲，配置文件不應該用編程語言來編寫，因爲它們需要能夠被不懂編程的系統管理人員編輯。但是，這種情況出現的機率有多大呢？我們真的希望不懂編程的系統管理人員來改變一個複雜的服務器端應用程序的事務隔離等級嗎？只有在非常簡單的時候，非編程語言的配置文件纔有最好的效果。如果配置信息開始變得複雜，就應該考慮選擇一種合適的編程語言來編寫配置文件。

在Java世界裏，我們聽到了來自配置文件的不和諧音——每個組件都有它自己的配置文件，而且格式還各不相同。如果你要使用一打這樣的組件，你就得維護一打的配置文件，那會很快讓你煩死。

在這裏，我的建議是：始終提供一種標準的配置方式，使程序員能夠通過同一個編程接口輕鬆地完成配置工作。至於其他的配置文件，僅僅把它們當作一種可選的功能。藉助這個編程接口，開發者可以輕鬆地管理配置文件。如果你編寫了一個組件，則可以由組件的使用者來選擇如何管理配置信息：使用你的編程接口、直接操作配置文件格式，或者定義他們自己的配置文件格式，並將其與你的編程接口相結合。

分離配置與使用

所有這一切的關鍵在於：服務的配置應該與使用分開。實際上，這是一個基本的設計原則——分離接口與實現。在面向對象程序裏，我們在一個地方用條件邏輯來決定具體實例化哪一個類，以後的條件分支都由多態來實現，而不是繼續重複前面的條件邏輯，這就是分離接口與實現的原則。

如果對於一段代碼而言，接口與實現的分離還只是有用的話，那麼當你需要使用外部元素（例如組件和服務）時，它就是生死攸關的大事。這裏的第一個問題是：你是否希望將選擇具體實現類的決策推遲到部署階段。如果是，那麼你需要使用插入技術。使用了插入技術之後，插件的裝配原則上是與應用程序的其餘部分分開的，這樣你就可以輕鬆地針對不同的部署替換不同的配置。這種配置機制可以通過服務定位器來實現（Service Locator模式），也可以藉助依賴注入直接完成（Dependency Injection 模式）。

結論和思考

在時下流行的輕量級容器都使用了一個共同的模式來組裝應用程序所需的服務，我把這個模式稱爲Dependency Injection，它可以有效地替代Service Locator模式。在開發應用程序時，兩者不相上下，但我認爲Service Locator模式略有優勢，因爲它的行爲方式更爲直觀。但是，如果你開發的組件要交給多個應用程序去使用，那麼Dependency Injection模式會是更好的選擇。

如果你決定使用Dependency Injection模式，這裏還有幾種不同的風格可供選擇。我建議你首先考慮構造函數注入；如果遇到了某些特定的問題，再改用設值方法注入。如果你要選擇一個容器，在其之上進行開發，我建議你選擇同時支持這兩種注入方式的容器。

Service Locator 模式和Dependency Injection 模式之間的選擇並非是最重要的，更重要的是：應該將服務的配置和應用程序內部對服務的使用分離開。

轉自：http://www.oschina.net/translate/ioc-and-injection?print

csf993981061

發佈了21 篇原創文章 · 獲贊 6 · 訪問量 5萬+

私信關注

控制反轉和依賴注入的設計模式

控制反轉和依賴注入模式

組件和服務

一個簡單的例子

控制反轉

依賴注入的幾種形式

使用PicoContainer 進行構造函數注入

使用Spring 進行設值方法注入

接口注入

使用Service Locator

爲定位器提供分離的接口

動態服務定位器

使用兼顧服務定位器和依賴注入

決定使用哪一個選項

服務定位器 vs 依賴注入

構造函數注入 vs. 設值方法注入

代碼配置or配置文件

分離配置與使用

更多的問題

結論和思考

TypedArray、attrs.xml、AttributeSet

通過Intent跳轉到系統應用

Scrollview嵌套HorizontalScrollView導致橫向滑動卡頓現象解決

SVN trunk branches tags

android 之 .9圖製作

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結