依賴注入（Ioc）的3種實現方式

Type1 介面注入
我們常常藉助介面來將調用者與實現者分離。如:    public class ClassA {
        private InterfaceB clzB;
        public doSomething() {
        Ojbect obj =
        Class.forName(Config.BImplementation).newInstance();
        clzB = (InterfaceB)obj;
        clzB.doIt();
        }
        ……
    }

上面的代碼中，ClassA依賴於InterfaceB的實現，如何獲得InterfaceB實作類別的執行個體？傳統的方法是在
代碼中建立InterfaceB實作類別的執行個體，並將起賦予clzB。
而這樣一來，ClassA在編譯期即依賴於InterfaceB的實現。為了將調用者與實現者在編譯期分離，於是有
了上面的代碼，我們根據預先在設定檔中設定的實作類別的類名(Config.BImplementation)，動態
載入實作類別，並通過InterfaceB強制轉型後為ClassA所用。這就是介面注入的一個最原始的雛形。
而對於一個Type1型IOC容器而言，載入介面實現並建立其執行個體的工作由容器完成。
如下面這個類:    public class ClassA {
        private InterfaceB clzB;
        public Object doSomething(InterfaceB b) {
        clzB = b;
        return clzB.doIt();
        }
        ……
    }

在運行期，InterfaceB執行個體將由容器提供。
Type1型IOC發展較早（有意或無意），在實際中得到了普遍應用，即使在IOC的概念尚未確立時，這樣的
方法也已經頻繁出現在我們的代碼中。
下面的代碼大家應該非常熟悉：    public class MyServlet extends HttpServlet {
        public void doGet(
        HttpServletRequest request,
        HttpServletResponse response)
        throws ServletException, IOException {
        ……
        }
    }

這也是一個Type1 型注入，HttpServletRequest和HttpServletResponse執行個體由Servlet Container
在運行期動態注入。
另，Apache Avalon是一個較為典型的Type1型IOC容器。

                                                                                  Type2 設值注入
在各種類型的依賴注入模式中，設值注入模式在實際開發中得到了最廣泛的應用（其中很大一部分得
力於Spring架構的影響）。
在筆者看來，基於設定模式的依賴注入機制更加直觀、也更加自然。Quick Start中的樣本，就是典
型的設定注入，即通過類的setter方法完成依賴關係的設定。

                                                                                  Type3 構造子注入

    public class DIByConstructor {
        private final DataSource dataSource;
        private final String message;
        public DIByConstructor(DataSource ds, String msg) {
        this.dataSource = ds;
        this.message = msg;
        }
        ……
    }

構造子注入，即通過建構函式完成依賴關係的設定，如：
可以看到，在Type3類型的依賴注入機制中，依賴關係是通過類建構函式建立，容器通過調用類的構
造方法，將其所需的依賴關係注入其中。
PicoContainer（另一種實現了依賴注入模式的輕量級容器）首先實現了Type3類型的依賴注入模式。

                                                                                 幾種依賴注入模式的對比總結
介面注入模式因為曆史較為悠久，在很多容器中都已經得到應用。但由於其在靈活性、易用性上不如
其他兩種注入模式，因而在IOC的專題世界內並不被看好。
Type2和Type3型的依賴注入實現則是目前主流的IOC實現模式。這兩種實現方式各有特點，也各具
優勢（一句經典廢話J）。

Type2 設值注入的優勢
1．對於習慣了傳統JavaBean開發的程式員而言，通過setter方法設定依賴關係顯得更加直
觀，更加自然。
2．如果依賴關係（或繼承關係）較為複雜，那麼Type3模式的建構函式也會相當龐大（我們需
要在建構函式中設定所有依賴關係），此時Type2模式往往更為簡潔。
3．對於某些第三方類庫而言，可能要求我們的組件必須提供一個預設的建構函式（如Struts
中的Action），此時Type3類型的依賴注入機制就體現出其局限性，難以完成我們期望的功
能。

Type3 構造子注入的優勢：
1． “在構造期即建立一個完整、合法的對象”，對於這條Java設計原則，Type3無疑是最好的
響應者。
2．避免了繁瑣的setter方法的編寫，所有依賴關係均在建構函式中設定，依賴關係集中呈現，
更加易讀。
3．由於沒有setter方法，依賴關係在構造時由容器一次性設定，因此組件在被建立之後即處於
相對“不變”的穩定點，無需擔心上層代碼在調用過程中執行setter方法對組件依賴關係
產生破壞，特別是對於Singleton模式的組件而言，這可能對整個系統產生重大的影響。
4．同樣，由於關聯關係僅在建構函式中表達，只有組件建立者需要關心組件內部的依賴關係。
對調用者而言，組件中的依賴關係處於黑盒之中。對上層屏蔽不必要的資訊，也為系統的
層次清晰性提供了保證。
5．通過構造子注入，意味著我們可以在建構函式中決定依賴關係的注入順序，對於一個大量
依賴外部服務的組件而言，依賴關係的獲得順序可能非常重要，比如某個依賴關係注入的
先決條件是組件的DataSource及相關資源已經被設定。文章引用自：