理解依賴註入和控制反轉

從一個任務開始講

某天，公司領導找到開發人員，說要開發一個微信支付寶的收款明細獲取功能，我們把這個任務作為一個案例進行說明。

第一步：設計

案例精簡：把任務指派給開發人員完成。本句話中，有兩個名詞：“任務”和“開發人員”，所以我們考慮設計兩個對象(任務和開發人員)。

開發人員對象：

package DependencyInjectionDemo;

public class Javaer {
    private String name;

    public Javaer(String name) {
        this.name = name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void WriteCode() {
        System.out.println(this.name + " writting java code...");
    }
}

任務對象：

package DependencyInjectionDemo;

public class NewTask {

    private String name;
    private Javaer javaer;

    public NewTask(String name) {
        this.name = name;
        this.javaer = new Javaer("張三");
    }

    public void Start() {
        System.out.println(this.name + " started ..");
        this.javaer.WriteCode();
    }
}

場景類：

package DependencyInjectionDemo;

public class DependencyInjectionDemo {

    public static void main(String[] args) {
        NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
        task.Start();
    }
}

運行結果：

開發微信支付寶收款明細獲取工具 started ..
張三 writting java code...

現在讓我們來分析一下這個設計存在的問題。

• 如果不追求復用和耦合，只是臨時完成任務，這麼寫倒也無可厚非;
• 如果再有別的任務指派給其他開發人員，我們需要去代碼內部修改編碼;
• 如果有很仰慕你的同事需要復用你的實現，你不能打包成jar文件給他直接用，因為他不能從jar文件外部修改任務和開發人員；

所以，我們應當讓用戶來指派開發人員，改進一下：

package DependencyInjectionDemo;

public class NewTask {

    private String name;
    private Javaer javaer;

    public NewTask(String name) {
        this.name = name;
        //this.javaer = new Javaer("張三"); 刪了啦
    }

    public void SetJavaer(Javaer javaer) {
        this.Javaer = javaer;
    }

    public void Start() {
        System.out.println(this.name + " started ..");
        this.javaer.WriteCode();
    }
}

場景類也要做一下修改：

package DependencyInjectionDemo;

public class DependencyInjectionDemo {

    public static void main(String[] args) {
        NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
        task.SetJavaer(new Javaer("張三")); //加入這句
        task.Start();
    }
}

輸出和前面的Demo是一樣的：

開發微信支付寶收款明細獲取工具 started ..
張三 writting java code...

現在，我們知道了一個事實，完成任務需要依賴特定的開發人員（NewTask類依賴Javaer類），開始時，NewTask類在構造時綁定開發人員，現在這種依賴可以在使用時按需要進行綁定。
這就是依賴註入

在上面的案例中，我們是通過Setter進行註入的，另外一種常用的註入方式是通過構造方法進行註入：

    public NewTask(String name, Javaer javaer) {
        this.name = name;
        this.javaer = javaer; //構造方法中進行註入
    }

這裡聯想一下，任務執行期間，任務執行者（本例中是張三）生病了，那麼就需要另外安排一名開發人員繼續任務的執行，怎麼辦呢？這個時候應該考慮的是Javaer這個對象的穩定性，如果開發人員這個對象穩定性非常高，我們可以考慮在NewTask的構造方法中進行註入，因為開發人員這個對象非常穩定，不會出現中途換帥的情況，但事實並非如此，張三生病了，就得允許不中斷任務的情況下，重新指派另一名開發人員繼續進行開發，很顯然，在這個場景中，我們應該使用Setter註入，不需要重新New一個NewTask（也就是任務重新開始），直接使用Setter更換開發人員即可。

這裡還有一種註入方式是配置文件註入，這就要求註入的對象穩定性非常高，甚至高到大於服務的生命周期（比如資料庫連接）。

第二步：需求挖掘

我們知道，一個開發團隊往往是多種開發語言並存的，有些任務適合用Java來完成，有些適合用C#，還有些任務適合用Python，現在問題來了，這個NewTask類庫的使用者發現：任務只能指派給Javaer。

所以為了更好的復用，我們的需求應該變成：任務既能指派給Javaer，也能指派給Pythoner和CSharper，以及其他任何以後可能加入的開發語言。

很自然的，我想到了使用介面:

package DependencyInjectionDemo;

public interface Coder {
    void WriteCode();
}

修改原來的Javaer,實現Coder介面：

package DependencyInjectionDemo;

public class Javaer implements Coder {
    private String name;

    public Javaer(String name) {
        this.name = name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void WriteCode() {
        System.out.println(this.name + " writting java code...");
    }
}

Python開發人員實現Coder介面：

package DependencyInjectionDemo;

public class Pythoner implements Coder{
    private String name;
    public Pythoner(String name) {
        this.name = name;
    }
    @Override
    public void WriteCode() {
        System.out.println(this.name + " writting python code...");
    }
}

C# 開發人員實現Coder介面：

package DependencyInjectionDemo;

public class CSharper implements Coder {

    private String name;

    public CSharper(String name) {
        this.name = name;
    }

    @Override
    public void WriteCode() {
        System.out.println(this.name + " writting c# code...");
    }
}

修改任務類中的Javaer為Coder：

public class NewTask {

    private String name;
    private Coder coder;

    public NewTask(String name) {
        this.name = name;
    }

    public void SetCoder(Coder coder) {
        this.coder= coder;
    }

    public void Start() {
        System.out.println(this.name + " started ..");
        this.coder.WriteCode();
    }
}

修改場景類：

package DependencyInjectionDemo;

public class DependencyInjectionDemo {

    public static void main(String[] args) {
        NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
        task.SetCoder(new Javaer("張三"));
        // 都是Coder，允許註入
        // task.SetCoder(new Pythoner("李四"));
        // task.SetCoder(new CSharper("王五"));
        task.Start();
    }
}

現在，我們可以指派任務給pythoner，CSharper和Javaer了，加入以後加入了Ruby或者Go語言開發人員，類庫的使用者只需要實現Coder介面，就可以把任務指派給新來的開發人員了，不需要修改NewTask代碼，實現了低耦合和可擴展性。

在講下麵的內容之前，我們先來熟悉一個名詞：控制反轉，四個字，拆成兩個詞，一個是控制，一個是反轉。結合上面的例子，我們的NewTask開始的時候依賴開發人員，其在內部主動創建了開發人員對象，後來我們發現這樣造成了強依賴，於是就把NewTask的主動創建開發人員這個操作撤銷了，修改成了在外部實現開發人員實例並傳入到NewTask內部，NewTask現在只能被動的接收我們創建的開發人員對象，從主動到被動，控制實現了反轉。

概念

控制反轉是原則，依賴註入是方式。

除了依賴註入(Dependency Injection, 簡稱DI)，還有另外一種方式是“依賴查找（Dependency Locate）”， 場景類需要服務類時，從一個獲取點主動取得指定的服務類。這種方式變被動接收註入為主動獲取，使得場景類在需要時主動獲取服務類，如我們向一個統管全局的Factory傳入一個字元串，Factory返回給我一個相應服務類的實例。

不過，不論使用簡單工廠（Simple Factory）還是抽象工廠（Abstract Factory），都避免不了判斷服務類類型或工廠類型，這樣系統中總要有一個地方存在不符合OCP的if…else或switch…case結構，這種缺陷是Simple Factory和Abstract Factory以及依賴獲取本身無法消除的，而在某些支持反射的語言中（如Java和C#），通過將反射機制的引入徹底解決了這個問題。

反射與依賴註入

上面的例子中，假設我們再增加一個語言的分支（如Go）而且使用了工廠模式（簡單或抽象工廠），我們需要實現Coder介面，雖然符合開閉原則（對擴展開放，對修改關閉），但最終，我們還是要回到工廠方法內部，去增加一個swith或ifelse分支，以完善我們的判斷，這就破壞了開閉原則。依賴註入本身是沒有能力解決這個問題的，但語言本身的反射機制（Reflection）卻能從根本上解決這個問題。

現在的問題是，最終我們找到的這個對象，還是需要通過“new”操作來實例化，那麼，我們如何通過不修改代碼的方式，“new”出一個新的實例呢？

來試著實現一下：

package DependencyInjectionDemo;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class DependencyInjectionDemo {

    private static String taskName; //任務
    private static String coderName; //語言
    private static String devName; //開發人員

    public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {

        /*現在我可以把這些寫到配置文件中了*/
        taskName = "新任務名稱";
        coderName = "Pythoner";
        devName = "小明";

        NewTask task = new NewTask(taskName);
        Coder coder = getCoder(coderName, devName);
        task.SetCoder(coder);

        /* 以前這麼寫 */
        // task.SetCoder(new Pythoner("李四"));
        // task.SetCoder(new CSharper("王五"));

        task.Start();
    }

    /**
     * 根據類名獲取類實例
     * @param coderName
     * @param name
     * @return 類的實例對象
     * @throws ClassNotFoundException
     * @throws NoSuchMethodException
     * @throws IllegalAccessException
     * @throws InvocationTargetException
     * @throws InstantiationException
     */
    public static Coder getCoder(String coderName, String name) throws ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        Constructor c = Class.forName("DependencyInjectionDemo."+coderName).getConstructor(String.class);
        Coder coder = (Coder)c.newInstance(new Object[] {name});
        return coder;
    }
}

輸出：

新任務名稱 started ..
小明 writting python code...

以上代碼，實現了一個根據類名獲取實例的getCoder方法，該方法有兩個參數，一個是類名，另一個是Coder的構造參數name。在場景操作中，分別定義了任務名稱，語言，開發人員三個變數，現在假設這些變數完全是從配置文件中讀取的，那麼，當我們以後增加新的語言，增加新的開發人員時，只需要新增加一個Coder介面的實現，然後修改配置文件即可。真正實現了OCP原則。怎麼樣？是不是感覺自己很牛逼？

以下為摘錄內容，來源:依賴註入那些事兒

IoC Container

說到依賴註入的話，就不能不提到IoC Container(IoC容器)，那麼到底什麼是IoC容器？我們還是先來看看它的出現背景。

我們知道，軟體開發領域有句著名的論斷：不要重覆發明輪子！因為軟體開發講求復用，所以，對於應用頻繁的需求，總是有人設計各種通用框架和類庫以減輕人們的開發負擔。例如，數據持久化是非常頻繁的需求，於是各種ORM框架應運而生；再如，對MVC的需求催生了Struts等一批用來實現MVC的框架。

隨著面向對象分析與設計的發展和成熟，OOA&D被越來越廣泛應用於各種項目中，然而，我們知道，用OO就不可能不用多態性，用多態性就不可能不用依賴註入，所以，依賴註入變成了非常頻繁的需求，而如果全部手工完成，不但負擔太重，而且還容易出錯。再加上反射機制的發明，於是，自然有人開始設計開發各種用於依賴註入的專用框架。這些專門用於實現依賴註入功能的組件或框架，就是IoC Container。

從這點看，IoC Container的出現有其歷史必然性。目前，最著名的IoC也許就是Java平臺上的Spring框架的IoC組件，而.NET平臺上也有Spring.NET和Unity等。

IoC Container 的分類

前面曾經討論了三種依賴註入方式，但是，想通過方式對IoC Container進行分類很困難，因為現在IoC Container都設計很完善，幾乎支持所有依賴註入方式。不過，根據不同框架的特性和慣用法，還是可以講IoC Container分為兩個大類。

• 重量級IoC Container
  所謂重量級IoC Container，是指一般用外部配置文件（一般是XML）作為依賴源，並托管整個系統各個類的實例化的IoC Container。這種IoC Container，一般是承接了整個系統幾乎所有多態性的依賴註入工作，並承接了所有服務類的實例化工作，而且這些實例化依賴於一個外部配置文件，這種IoC Container，很像通過一個文件，定義整個系統多態結構，視野巨集大，想要很好駕馭這種IoC Container，需要一定的架構設計能力和豐富的實踐經驗。

  Spring和Spring.NET是重量級IoC Container的例子。一般來說，這種IoC Container穩定性有餘而活性不足，適合進行低活多態性的依賴註入。

• 輕量級IoC Container

  還有一種IoC Container，一般不依賴外部配置文件，而主要使用傳參的Setter或Construtor註入，這種IoC Container叫做輕量級IoC Container。這種框架很靈活，使用方便，但往往不穩定，而且依賴點都是程式中的字元串參數，所以，不適合需要大規模替換和相對穩定的低活多態性，而對於高活多態性，有很好的效果。

  Unity是一個典型的輕量級IoC Container。

參考文獻

依賴註入那些事兒
輕鬆理解 Java開發中的依賴註入(DI)和控制反轉(IOC)