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

2019-11-18 13:00:10

字體：大中小

供稿：網(wǎng)友

　　Type1 接口注入
　　
　　我們經(jīng)常借助接口來將調(diào)用者與實現(xiàn)者分離。如:
　　public class ClassA {
　　PRivate InterfaceB clzB;
　　public init() {
　　Ojbect obj =
　　Class.forName(Config.BImplementation).newInstance();
　　clzB = (InterfaceB)obj;
　　}
　　……
　　}
　　
　　上面的代碼中，ClassA依靠于InterfaceB的實現(xiàn)，如何獲得InterfaceB實現(xiàn)類的實例？傳統(tǒng)的方法是在代碼中創(chuàng)建InterfaceB實現(xiàn)類的實例，并將起賦予clzB.
　　
　　而這樣一來，ClassA在編譯期即依靠于InterfaceB的實現(xiàn)。為了將調(diào)用者與實現(xiàn)者在編譯期分離，于是有了上面的代碼，我們根據(jù)預先在配置文件中設定的實現(xiàn)類的類名，動態(tài)加載實現(xiàn)類，并通過InterfaceB強制轉(zhuǎn)型后為ClassA所用。
　　
　　這就是接口注入的一個最原始的雛形。
　　
　　而對于一個Type1型IOC容器而言，加載接口實現(xiàn)并創(chuàng)建其實例的工作由容器完成，如J2EE開發(fā)中常用的Context.lookup（ServletContext.getXXX），都是Type1型IOC的表現(xiàn)形式。
　　
　　Apache Avalon是一個典型的Type1型IOC容器。
　　
　　Type2 構造子注入
　　
　　構造子注入，即通過構造函數(shù)完成依靠關系的設定，如：
　　public class DIByConstrUCtor {
　　private final DataSource dataSource;
　　private final String message;
　　public DIByConstructor(DataSource ds, String msg) {
　　this.dataSource = ds;
　　this.message = msg;
　　}
　　……
　　}
　　
　　可以看到，在Type2類型的依靠注入機制中，依靠關系是通過類構造函數(shù)建立，容器通過調(diào)用類的構造方法，將其所需的依靠關系注入其中。
　　
　　PicoContainer（另一種實現(xiàn)了依靠注入模式的輕量級容器）首先實現(xiàn)了Type2類型的依靠注入模式。
　　
　　Type3 設值注入
　　
　　在各種類型的依靠注入模式中，設值注入模式在實際開發(fā)中得到了最廣泛的應用（其中很大一部分得力于Spring框架的影響）。
　　
　　在筆者看來，基于設置模式的依靠注入機制更加直觀、也更加自然。Quick Start中的示例，就是典型的設置注入，即通過類的setter方法完成依靠關系的設置。
　　
　　SpringFrameWork Developer’s Guide Version 0.6
　　September 2, 2004 So many open source projects. Why not Open your Documents?
　　
　　幾種依靠注入模式的對比總結(jié)
　　
　　接口注入模式因為具備侵入性，它要求組件必須與特定的接口相關聯(lián)，因此并不被看好，實際使用有限。
　　
　　Type2和Type3的依靠注入實現(xiàn)模式均具備無侵入性的特點。在筆者看來，這兩種實現(xiàn)方式各有特點，也各具優(yōu)勢（一句經(jīng)典廢話？）。
　　
　　Type2 構造子注入的優(yōu)勢：
　　
　　1. “在構造期即創(chuàng)建一個完整、合法的對象”，對于這條java設計原則，Type2無疑是最好的響應者。
　　
　　我的理解：就是你要通過一種方式來保證對象的引用完整性，type2選擇了構造器的方式來實現(xiàn)。
　　
　　2. 避免了繁瑣的setter方法的編寫，所有依靠關系均在構造函數(shù)中設定，依靠關系集中呈現(xiàn)，更加易讀。
　　
　　我的理解：使用構造方法就不需要每個屬性都寫set和get方法了，這樣省去了很多的代碼。
　　
　　3. 由于沒有setter方法，依靠關系在構造時由容器一次性設定，因此組件在被創(chuàng)建之后即處于相對“不變”的穩(wěn)定狀態(tài)，無需擔心上層代碼在調(diào)用過程中執(zhí)行setter方法對組件依靠關系產(chǎn)生破壞，非凡是對于Singleton模式的組件而言，這可能對整個系統(tǒng)產(chǎn)生重大的影響。
　　
　　我的理解：使用構造器來實現(xiàn)，那么你需要一次對所有的屬性都初始話，相對set方法來說，缺少了一些靈活性。
　　
　　4. 同樣，由于關聯(lián)關系僅在構造函數(shù)中表達，只有組件創(chuàng)建者需要關心組件內(nèi)部的依靠關系。對調(diào)用者而言，組件中的依靠關系處于黑盒之中。對上層屏蔽不必要的信息，也為系統(tǒng)的層次清楚性提供了保證。
　　
　　我的理解： spring的這設計就是要屏蔽依靠關系，你只需要對接口編程，而不需要考慮依靠關系的實現(xiàn)。所以對調(diào)用者來說，依靠關系是處于黑盒當中。
　　
　　5. 通過構造子注入，意味著我們可以在構造函數(shù)中決定依靠關系的注入順序，對于一個大量依靠外部服務的組件而言，依靠關系的獲得順序可能非常重要，比如某個依靠關系注入的先決條件是組件的DataSource及相關資源已經(jīng)被設定。
　　
　　我的理解：關于順序問題，我們來看以下兩段代碼：
　　public DIByConstructor(DataSource ds, String msg) {
　　this.dataSource = ds;
　　this.message = msg;
　　}
　　public DIByConstructor(DataSource ds, String msg) {
　　this.dataSource = ds;
　　this.message = msg;
　　}
　　
　　在本例中，順序不太重要，但是假如message的初始化需要用到datasource 的話，那么就必須要先初始化datasource,所以相對來說，順序就是確定了。
　　
　　Type3 設值注入的優(yōu)勢
　　
　　1. 對于習慣了傳統(tǒng)JavaBean開發(fā)的程序員而言，通過setter方法設定依靠關系顯得更加直觀，更加自然。
　　
　　2. 假如依靠關系（或繼續(xù)關系）較為復雜，那么Type2模式的構造函數(shù)也會相當龐大（我們需要在構造函數(shù)中設定所有依靠關系），此時Type3模式往往更為簡潔。
　　
　　我的理解：依靠關系（或繼續(xù)關系）較為復雜，指的是，屬性較多，需要寫很多的set和get方法。
　　
　　3. 對于某些第三方類庫而言，可能要求我們的組件必須提供一個默認的構造函數(shù)（如Struts中的Action），此時Type2類型的依靠注入機制就體現(xiàn)出其局限性，難以完成我們期望的功能。
　　
　　可見，Type2和Type3模式各有千秋，而Spring、PicoContainer都對Type2和Type3類型的依靠注入機制提供了良好支持。這也就為我們提供了更多的選擇余地。理論上，以Type2類型為主，輔之以Type3類型機制作為補充，可以達到最好的依靠注入效果，不過對于基于Spring Framework開發(fā)的應用而言，Type3使用更加廣泛。

上一篇：開源有益——愛上Spring的5個理由

下一篇：Spring創(chuàng)建一個簡單的工作流引擎(圖)