Spring IOC三種注入方式比較

物件與物件之間的關係可以簡單的理解為物件之間的依賴關係:
A類需要B類的一個例項來進行某些操作,比如在A類的方法中需要呼叫B類的方法來完成功能,叫做A類依賴於B類.
控制反轉是一種將元件依賴關係的建立和管理置於程式外部的技術,由容器控制程式之間的關係,而不是由程式碼直接控制.

1.介面注入

public class ClassA {
  private InterfaceB clzB;
  public void doSomething() {
    Ojbect obj = Class.forName(Config.BImplementation).newInstance();
    clzB = (InterfaceB)obj;
    clzB.doIt();
  }
……
}

上面程式碼中,ClassA依賴於InterfaceB的實現,如何獲得InterfaceB實現類的例項?傳統的方法是在程式碼中建立 InterfaceB實現類的例項,並將賦予clzB.這樣一來,ClassA在編譯期即依賴於InterfaceB的實現.為了將呼叫者與實現者在編譯 期分離,於是有了上面的程式碼.
我們根據預先在配置檔案中設定的實現類的類名(Config.BImplementation),動態載入實現類,並透過InterfaceB強制轉型後為ClassA所用,這就是介面注入的一個最原始的雛形.

public class ClassA {
  private InterfaceB clzB;
  public Object doSomething(InterfaceB b) {
    clzB = b;
    return clzB.doIt();
  }
……
}

上面程式碼中,載入介面實現並建立其例項的工作由容器完成.
在執行期,InterfaceB例項將由容器提供.即使在IOC的概念尚未確立時,這樣的方法也已經頻繁出現在我們的程式碼中.

public class MyServlet extends HttpServlet {
  public void doGet(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException {
    ……
  }
}

HttpServletRequest和HttpServletResponse例項由Servlet Container在執行期動態注入.

2.Setter設定注入
基於設定模式的依賴注入機制更加直觀,也更加自然.

public class ClassA {
  private InterfaceB clzB;
  public void setClzB(InterfaceB clzB) {
    this.clzB = clzB;
  }
……
}

3.構造器注入

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

構造器注入,即透過建構函式完成依賴關係的設定,容器透過呼叫類的構造方法將其所需的依賴關係注入其中.

三種注入方式比較:

介面注入：

介面注入模式因為具備侵入性，它要求元件必須與特定的介面相關聯，因此並不被看好，實際使用有限。

Setter 注入：

對於習慣了傳統 javabean 開發的程式設計師，透過 setter 方法設定依賴關係更加直觀。

如果依賴關係較為複雜，那麼構造子注入模式的建構函式也會相當龐大，而此時設值注入模式則更為簡潔。

如果用到了第三方類庫，可能要求我們的元件提供一個預設的建構函式，此時構造子注入模式也不適用。

構造器注入：

在構造期間完成一個完整的、合法的物件。

所有依賴關係在建構函式中集中呈現。

依賴關係在構造時由容器一次性設定，元件被建立之後一直處於相對“不變”的穩定狀態。

只有元件的建立者關心其內部依賴關係，對呼叫者而言，該依賴關係處於“黑盒”之中。

總結

Spring使用注入方式，為什麼使用注入方式，這系列問題實際歸結起來就是一句話，Spring的注入和IoC（本人關於IoC的闡述）反轉控制是一回事。

理論上：第三種注入方式（建構函式注入）在符合java使用原則上更加合理，第二種注入方式（setter注入）作為補充。

實際上：我個人認為第二種注入方式（setter注入）可以取得更加直觀的效果，在使用工作上有不可比擬的優勢，所以setter注入依賴關係應用更加廣泛。