1.5 實現依賴注入1.5.1 背景介紹

設計模式中，尤其是結構型模式很多時候解決的就是物件間的依賴關係，變依賴具體為依賴抽象。平時開發中如果發現客戶程式依賴某個（或某類）物件，我們常常會對它們進行一次抽象，形成抽象的抽象類、介面，這樣客戶程式就可以擺脫所依賴的具體型別。

這個過程中有個環節被忽略了——誰來選擇客戶程式需要的滿足抽象型別的具體型別呢？通過後面的介紹你會發現很多時候建立型模式可以比較優雅地解決這個問題。但另一問題出現了，如果您設計的不是具體業務邏輯，而是公共庫或框架程式，這時候您是一個“服務方”，不是您呼叫那些構造型別，而是它們把抽象型別傳給您，怎麼鬆散地把加工好的抽象型別傳遞給客戶程式就是另一回事了。

    這個情形也就是常說的“控制反轉”，IOC：Inverse of Control；框架程式與抽象型別的呼叫關係就像常說的好萊塢規則：Don’t call me, I’ll call you.

參考Martin Fowler在《Inversion of Control Containers and the Dependency Injection pattern》一文，我們可以採用“依賴注入”的方式將加工好的抽象型別例項“注入”到客戶程式中，本書的示例也將大量採用這種方式將各種依賴項“注入”到模式實現的外部——客戶程式。下面我們結合一個具體的示例看看為什麼需要依賴注入，以及Martin Fowler文中提到的三種經典方式，然後依據C#語言的特質，再擴展出一個基於Attribter方式注入（參考原有的Setter命名，這裡將基於Attribute的方法稱為Attributer）。

1.5.2 示例情景

客戶程式需要一個提供System.DateTime型別當前系統時間的物件，然後根據需要僅僅把其中的年份部分提取出來，因此最初的實現程式碼如下：

C#

using System;

using System.Diagnostics;

namespace MarvellousWorks.PracticalPattern.Concept.DependencyInjection.Example1

{

    class TimeProvider

    {

        public DateTime CurrentDate { get { return DateTime.Now; } }

    }

    public class Client

    {

        public int GetYear()

        {

            TimeProvider timeProvier = new TimeProvider();

            return timeProvier.CurrentDate.Year;

        }

    }

}

後來因為某種原因，發現使用.NET Framework自帶的日期型別精度不夠，需要提供其他來源的TimeProvider，確保在不同精度要求的功能模組中使用不同的TimeProvider。這樣問題集中在TimeProvider的變化會影響客戶程式，但其實客戶程式僅需要抽象地使用其獲取當前時間的方法。為此，增加一個抽象介面，確保客戶程式僅依賴這個介面ITimeProvider，由於這部分客戶程式僅需要精確到年，因此它可以使用一個名為SystemTimeProvider (:ITimeProvider)的型別。新的實現程式碼如下：

C#

using System;

namespace 
   MarvellousWorks.PracticalPattern.Concept.DependencyInjection.Example2

{

    interface ITimeProvider

    {

        DateTime CurrentDate { get;}

    }

    class TimeProvider : ITimeProvider

    {

        public DateTime CurrentDate { get { return DateTime.Now; } }

    }

    public class Client

    {

        public int GetYear()

        {

            ITimeProvider timeProvier = new TimeProvider();

            return timeProvier.CurrentDate.Year;

        }

    }

}

這樣看上去客戶程式後續處理權都依賴於抽象的ITimeProvider，問題似乎解決了？沒有，它還要知道具體的SystemTimeProvider。因此，需要增加一個物件，由它選擇某種方式把ITimeProvider例項傳遞給客戶程式，這個物件被稱為Assembler。新的結構如圖1-19所示。

圖1-19 增建裝配物件後新的依賴關係

其中，Assembler的職責如下：

l          知道每個具體TimeProviderImpl的型別。

l          可根據客戶程式的需要，將抽象ITimeProvider反饋給客戶程式。

l          本身還負責對TimeProviderImpl的建立。

下面是一個Assembler的示例實現：

C#

public class Assembler

{

    ///

    /// 儲存“抽象型別/實體型別”對應關係的字典

    ///

    private static Dictionary dictionary = 
       new Dictionary();

    static Assembler()

    {

        // 註冊抽象型別需要使用的實體型別

        // 實際的配置資訊可以從外層機制獲得,例如通過配置定義

        dictionary.Add(typeof(ITimeProvider), typeof(SystemTimeProvider));

    }

    /// 根據客戶程式需要的抽象型別選擇相應的實體型別，並返回型別例項

    /// 實體型別例項

    public object Create(Type type)     // 主要用於非泛型方式呼叫

    {

        if ((type == null) || !dictionary.ContainsKey(type)) throw new 
            NullReferenceException();

        Type targetType = dictionary[type];

        return Activator.CreateInstance(targetType);

    }

    /// 抽象型別（抽象類/介面/或者某種基類）

    public T Create()    // 主要用於泛型方式呼叫

    {

        return (T)Create(typeof(T));

    }

}

1.5.3 Constructor注入

建構函式注入，顧名思義，就是在建構函式的時候，通過Assembler或其他機制把抽象型別作為引數傳遞給客戶型別。這種方式雖然相對其他方式有些粗糙，而且僅在構造過程中通過“一錘子”方式設定好，但很多時候我們設計上正好就需要這種Read Only的注入方式。其實現方式如下：

C#

/// 在建構函式中注入

class Client

{

    private ITimeProvider timeProvider;

    public Client(ITimeProvider timeProvider)

    {

        this.timeProvider = timeProvider;

    }

}

Unit Test

[TestClass]

public class TestClient

{

    [TestMethod]

    public void Test()

    {

        ITimeProvider timeProvider = 
           (new Assembler()).Create();

        Assert.IsNotNull(timeProvider);     // 確認可以正常獲得抽象型別例項

        Client client = new Client(timeProvider);   // 在建構函式中注入

    }

}

1.5.4 Setter注入

Setter注入是通過屬性賦值的辦法解決的，由於Java等很多語言中沒有真正的屬性，所以Setter注入一般通過一個set()方法實現，C#語言由於本身就有可寫屬性，所以實現起來更簡潔，更像Setter。相比較Constructor方式而言，Setter給了客戶型別後續修改的機會，它比較適應於客戶型別例項存活時間較長，但Assembler修改抽象型別指定的具體實體型別相對較快的情景；不過也可以由客戶程式根據需要動態設定所需的型別。其實現方式如下：

C#

/// 通過Setter實現注入

class Client

{

    private ITimeProvider timeProvider;

    public ITimeProvider TimeProvider

    {

        get { return this.timeProvider; }   // getter本身和以Setter方式實現
                                                       注入沒有關係

        set { this.timeProvider = value; } // Setter

    }

}

Unit Test

[TestClass]

public class TestClient

{

    [TestMethod]

    public void Test()

    {

        ITimeProvider timeProvider = 
           (new Assembler()).Create();

         Assert.IsNotNull(timeProvider);     // 確認可以正常獲得抽象型別例項

        Client client = new Client();

        client.TimeProvider = timeProvider; // 通過Setter實現注入

    }

}

1.5.5 介面注入

介面注入是將包括抽象型別注入的入口以方法的形式定義在一個接口裡，如果客戶型別需要實現這個注入過程，則實現這個介面，客戶型別自己考慮如何把抽象型別“引入”內部。實際上介面注入有很強的侵入性，除了要求客戶型別增加需要的Setter或Constructor注入的程式碼外，還顯式地定義了一個新的介面並要求客戶型別實現它。除非還有更外層容器使用的要求，或者有完善的配置系統，可以通過反射動態實現介面方式注入，否則筆者並不建議採用介面注入方式。

既然Martin Fowler文中提到了這個實現方式，就給出如下示例：

C#

/// 定義需要注入ITimeProvider的型別

interface IObjectWithTimeProvider

{

    ITimeProvider TimeProvider { get;set;}

}

/// 通過介面方式注入

class Client : IObjectWithTimeProvider

{

    private ITimeProvider timeProvider;

    /// IObjectWithTimeProvider Members

    public ITimeProvider TimeProvider

    {

        get { return this.timeProvider; }

         set { this.timeProvider = value; }

    }

}

Unit Test

[TestClass]

public class TestClient

{

    [TestMethod]

    public void Test()

    {

        ITimeProvider timeProvider = (new 
              Assembler()).Create();

        Assert.IsNotNull(timeProvider);     // 確認可以正常獲得抽象型別例項

        IObjectWithTimeProvider objectWithTimeProvider = new Client();

        objectWithTimeProvider.TimeProvider = timeProvider; // 通過介面方式注入

    }

}

1.5.6 基於Attribute實現注入——Attributer

如果做個歸納，Martin Fowler之前所介紹的三種模式都是在物件部分進行擴充套件的，隨著語言的發展（.NET從1.0開始，Java從5開始），很多在類元資料層次擴充套件的機制相繼出現，比如C#可以通過Attribute將附加的內容注入到物件上。直觀上的客戶物件有可能在使用上做出讓步以適應這種變化，但這違背了依賴注入的初衷，三個角色（客戶物件、Assembler、抽象型別）之中兩個不能變，那隻好在Assembler上下功夫，誰叫它的職責就是負責組裝呢？

為了實現上的簡潔，上面三個經典實現方式實際將抽象物件注入到客戶型別都是在客戶程式中（也就是那三個Unit Test部分）完成的，其實同樣可以把這個工作交給Assembler完成；而對於Attribute方式注入，最簡單的方式則是直接把實現了抽象型別的Attribute定義在客戶型別上，例如：

C#

(錯誤的實現情況)

    class SystemTimeAttribute : Attribute, ITimeProvider { … }

    [SystemTime]

    class Client { … }

相信您也發現了，這樣雖然把客戶型別需要的ITimeProvider通過“貼標籤”的方式告訴它了，但事實上又把客戶程式與SystemTimeAttribute“綁”上了，它們緊密地耦合在一起。參考上面的三個實現，當抽象型別與客戶物件耦合的時候我們引入了Assembler，當Attribute方式出現類似的情況時，我們寫個AttributeAssembler不就行了麼？還不行。設計上要把Attribute設計成一個“通道”，考慮到擴充套件和通用性，它本身要協助AttributeAssembler完成ITimeProvider的裝配，最好還可以同時裝載其他抽象型別來修飾客戶型別。示例程式碼如下：

C#

[AttributeUsage(AttributeTargets.Class, AllowMultiple=true)]

sealed class DecoratorAttribute : Attribute

{

    /// 實現客戶型別實際需要的抽象型別的實體型別例項，即得注入客戶型別的內容

    public readonly object Injector;

    private Type type;

    public DecoratorAttribute(Type type)

    {

        if (type == null) throw new ArgumentNullException("type");

        this.type = type;

        Injector = (new Assembler()).Create(this.type);

    }

    /// 客戶型別需要的抽象物件型別

    public Type Type { get { return this.type; } }

}

/// 幫助客戶型別和客戶程式獲取其Attribute定義中需要的抽象型別例項的工具類

static class AttributeHelper

{

    public static T Injector(object target)

        where T : class

    {

        if (target == null) throw new ArgumentNullException("target");

        Type targetType = target.GetType();

        object[] attributes = targetType.GetCustomAttributes(
              typeof(DecoratorAttribute), false);

        if ((attributes == null) || (attributes.Length <= 0)) return null ;

        foreach (DecoratorAttribute attribute in 
           (DecoratorAttribute[])attributes)

            if (attribute.Type == typeof(T))

                return (T)attribute.Injector;

        return null;

    }

}

[Decorator(typeof(ITimeProvider))]

// 應用Attribute，定義需要將ITimeProvider通過它注入

class Client

{

    public int GetYear()

    {

        // 與其他方式注入不同的是，這裡使用的ITimeProvider來自自己的Attribute

        ITimeProvider provider = 
             AttributeHelper.Injector(this);

        return provider.CurrentDate.Year;

    }

}

Unit Test

    [TestMethod]

    public void Test()

    {

        Client client = new Client();

        Assert.IsTrue(client.GetYear() > 0);

    }

1.5.7 小結

依賴注入雖然被Martin Fowler稱為一個模式，但平時使用中，它更多地作為一項實現技巧出現，開發中很多時候需要藉助這項技巧把各個設計模式所加工的成果傳遞給客戶程式。各種實現方式雖然最終目標一致，但在使用特性上有很多區別。

l          Constructor方式：它的注入是一次性的，當客戶型別構造的時候就確定了。它很適合那種生命期不長的物件，比如在其存續期間不需要重新適配的物件。此外，相對Setter方式而言，在實現上Constructor可以節省很多程式碼；

l          Setter方式：一個很靈活的實現方式，對於生命期較長的客戶物件而言，可以在執行過程中隨時適配；

l          介面方式：作為注入方式具有侵入性，很大程度上它適於需要同時約束一批客戶型別的情況；

l          屬性方式：隨著開發語言的發展引入的新方式，它本身具有範圍較小的固定內容侵入性（一個DecoratorAttribute），它也很適合需要同時約束一批客戶型別情景。它本身實現相對複雜一些，但客戶型別使用的時候非常方便——“打標籤”即可。

1.5 實現依賴注入1.5.1 背景介紹

設計模式中，尤其是結構型模式很多時候解決的就是物件間的依賴關係，變依賴具體為依賴抽象。平時開發中如果發現客戶程式依賴某個（或某類）物件，我們常常會對它們進行一次抽象，形成抽象的抽象類、介面，這樣客戶程式就可以擺脫所依賴的具體型別。

這個過程中有個環節被忽略了——誰來選擇客戶程式需要的滿足抽象型別的具體型別呢？通過後面的介紹你會發現很多時候建立型模式可以比較優雅地解決這個問題。但另一問題出現了，如果您設計的不是具體業務邏輯，而是公共庫或框架程式，這時候您是一個“服務方”，不是您呼叫那些構造型別，而是它們把抽象型別傳給您，怎麼鬆散地把加工好的抽象型別傳遞給客戶程式就是另一回事了。

    這個情形也就是常說的“控制反轉”，IOC：Inverse of Control；框架程式與抽象型別的呼叫關係就像常說的好萊塢規則：Don’t call me, I’ll call you.

參考Martin Fowler在《Inversion of Control Containers and the Dependency Injection pattern》一文，我們可以採用“依賴注入”的方式將加工好的抽象型別例項“注入”到客戶程式中，本書的示例也將大量採用這種方式將各種依賴項“注入”到模式實現的外部——客戶程式。下面我們結合一個具體的示例看看為什麼需要依賴注入，以及Martin Fowler文中提到的三種經典方式，然後依據C#語言的特質，再擴展出一個基於Attribter方式注入（參考原有的Setter命名，這裡將基於Attribute的方法稱為Attributer）。

1.5.2 示例情景

客戶程式需要一個提供System.DateTime型別當前系統時間的物件，然後根據需要僅僅把其中的年份部分提取出來，因此最初的實現程式碼如下：

C#

using System;

using System.Diagnostics;

namespace MarvellousWorks.PracticalPattern.Concept.DependencyInjection.Example1

{

    class TimeProvider

    {

相關推薦