依賴注入的幾種實現類型

(1)Type1 接口注入
加載接口實現并創建其實例的工作由容器完成。在運行期，***實例將由容器提供。

public class MyServlet extends HttpServlet {
????public void doGet(
????HttpServletRequest request,
????HttpServletResponse response)
????throws ServletException, IOException {
???????……
????}
}
這也是一個Type1 型注入，HttpServletRequest和HttpServletResponse實例由Servlet Container在運行期動態注入。

(2)Type2 設值注入

(3)Type3 構造子注入
構造子注入，即通過構造函數完成依賴關系的設定，如：

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

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

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