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及相關資源已經被設定。