對Spring中接口注入的理解實例分析

　　Type 接口注入
　　
　　我們常常借助接口來將調用者與實現者分離如:
　　public class ClassA {
　　private InterfaceB clzB;
　　public init() {
　　Ojbect obj =
　　ClassforName(ConfigBImplementation)newInstance();
　　clzB = (InterfaceB)obj;
　　}
　　……
　　}
　　
　　上面的代碼中ClassA依賴於InterfaceB的實現如何獲得InterfaceB實現類的實例？傳統的方法是在代碼中創建InterfaceB實現類的實例並將起賦予clzB
　　
　　而這樣一來ClassA在編譯期即依賴於InterfaceB的實現為了將調用者與實現者在編譯期分離於是有了上面的代碼我們根據預先在配置文件中設定的實現類的類名動態加載實現類並通過InterfaceB強制轉型後為ClassA所用
　　
　　這就是接口注入的一個最原始的雛形
　　
　　而對於一個Type型IOC容器而言加載接口實現並創建其實例的工作由容器完成如JEE開發中常用的Contextlookup（ServletContextgetXXX）都是Type型IOC的表現形式
　　
　　Apache Avalon是一個典型的Type型IOC容器
　　
　　Type 構造子注入
　　
　　構造子注入即通過構造函數完成依賴關系的設定如
　　public class DIByConstructor {
　　private final DataSource dataSource;
　　private final String message;
　　public DIByConstructor(DataSource ds String msg) {
　　thisdataSource = ds;
　　ssage = msg;
　　}
　　……
　　}
　　
　　可以看到在Type類型的依賴注入機制中依賴關系是通過類構造函數建立容器通過調用類的構造方法將其所需的依賴關系注入其中
　　
　　PicoContainer（另一種實現了依賴注入模式的輕量級容器）首先實現了Type類型的依賴注入模式
　　
　　Type 設值注入
　　
　　在各種類型的依賴注入模式中設值注入模式在實際開發中得到了最廣泛的應用（其中很大一部分得力於Spring框架的影響）
　　
　　在筆者看來基於設置模式的依賴注入機制更加直觀也更加自然Quick Start中的示例就是典型的設置注入即通過類的setter方法完成依賴關系的設置
　　
　　SpringFrameWork Developers Guide Version
　　September So many open source projects Why not Open your Documents?
　　
　　幾種依賴注入模式的對比總結
　　
　　接口注入模式因為具備侵入性它要求組件必須與特定的接口相關聯因此並不被看好實際使用有限
　　
　　Type和Type的依賴注入實現模式均具備無侵入性的特點在筆者看來這兩種實現方式各有特點也各具優勢（一句經典廢話？）
　　
　　Type 構造子注入的優勢
　　
　　 在構造期即創建一個完整合法的對象對於這條Java設計原則Type無疑是最好的響應者
　　
　　我的理解就是你要通過一種方式來保證對象的引用完整性type選擇了構造器的方式來實現
　　
　　 避免了繁瑣的setter方法的編寫所有依賴關系均在構造函數中設定依賴關系集中呈現更加易讀
　　
　　我的理解使用構造方法就不需要每個屬性都寫set和get方法了這樣省去了很多的代碼
　　
　　 由於沒有setter方法依賴關系在構造時由容器一次性設定因此組件在被創建之後即處於相對不變的穩定狀態無需擔心上層代碼在調用過程中執行setter方法對組件依賴關系產生破壞特別是對於Singleton模式的組件而言這可能對整個系統產生重大的影響
　　
　　我的理解使用構造器來實現那麼你需要一次對所有的屬性都初始話相對set方法來說缺少了一些靈活性
　　
　　 同樣由於關聯關系僅在構造函數中表達只有組件創建者需要關心組件內部的依賴關系對調用者而言組件中的依賴關系處於黑盒之中對上層屏蔽不必要的信息也為系統的層次清晰性提供了保證
　　
　　我的理解 spring的這設計就是要屏蔽依賴關系你只需要對接口編程而不需要考慮依賴關系的實現所以對調用者來說依賴關系是處於黑盒當中
　　
　　 通過構造子注入意味著我們可以在構造函數中決定依賴關系的注入順序對於一個大量依賴外部服務的組件而言依賴關系的獲得順序可能非常重要比如某個依賴關系注入的先決條件是組件的DataSource及相關資源已經被設定
　　
　　我的理解關於順序問題我們來看以下兩段代碼
　　public DIByConstructor(DataSource ds String msg) {
　　thisdataSource = ds;
　　ssage = msg;
　　}
　　public DIByConstructor(DataSource ds String msg) {
　　thisdataSource = ds;
　　ssage = msg;
　　}
　　
　　在本例中順序不太重要但是如果message的初始化需要用到datasource 的話那麼就必須要先初始化datasource所以相對來說順序就是確定了
　　
　　Type 設值注入的優勢
　　
　　 對於習慣了傳統JavaBean開發的程序員而言通過setter方法設定依賴關系顯得更加直觀更加自然
　　
　　 如果依賴關系（或繼承關系）較為復雜那麼Type模式的構造函數也會相當龐大（我們需要在構造函數中設定所有依賴關系）此時Type模式往往更為簡潔
　　
　　我的理解依賴關系（或繼承關系）較為復雜指的是屬性較多需要寫很多的set和get方法
　　
　　 對於某些第三方類庫而言可能要求我們的組件必須提供一個默認的構造函數（如Struts中的Action）此時Type類型的依賴注入機制就體現出其局限性難以完成我們期望的功能
　　
　　可見Type和Type模式各有千秋而SpringPicoContainer都對Type和Type類型的依賴注入機制提供了良好支持這也就為我們提供了更多的選擇余地理論上以Type類型為主輔之以Type類型機制作為補充可以達到最好的依賴注入效果不過對於基於Spring Framework開發的應用而言Type使用更加廣泛
　　

From:http://tw.wingwit.com/Article/program/Java/ky/201311/28069.html