從一個任務開始講
某天，公司領導找到開發人員，說要開發一個微信支付寶的收款明細獲取功能，我們把這個任務作爲一個案例進行說明。
第一步：設計
案例精簡：把任務指派給開發人員完成。本句話中，有兩個名詞：“任務”和“開發人員”，所以我們考慮設計兩個對象(任務和開發人員)。
開發人員對象：
package DependencyInjectionDemo;
public class Javaer {
private String name;
public Javaer(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public void WriteCode() {
System.out.println(this.name + " writting java code...");
}
}
任務對象：
package DependencyInjectionDemo;
public class NewTask {
private String name;
private Javaer javaer;
public NewTask(String name) {
this.name = name;
this.javaer = new Javaer("張三");
}
public void Start() {
System.out.println(this.name + " started ..");
this.javaer.WriteCode();
}
}
場景類：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
task.Start();
}
}
運行結果：
開發微信支付寶收款明細獲取工具 started ..
張三 writting java code...
現在讓我們來分析一下這個設計存在的問題。
- 如果不追求複用和耦合，只是臨時完成任務，這麼寫倒也無可厚非;
- 如果再有別的任務指派給其他開發人員，我們需要去代碼內部修改編碼;
- 如果有很仰慕你的同事需要複用你的實現，你不能打包成jar文件給他直接用，因爲他不能從jar文件外部修改任務和開發人員；
所以，我們應當讓用戶來指派開發人員，改進一下：
package DependencyInjectionDemo;
public class NewTask {
private String name;
private Javaer javaer;
public NewTask(String name) {
this.name = name;
//this.javaer = new Javaer("張三"); 刪了啦
}
public void SetJavaer(Javaer javaer) {
this.Javaer = javaer;
}
public void Start() {
System.out.println(this.name + " started ..");
this.javaer.WriteCode();
}
}
場景類也要做一下修改：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
task.SetJavaer(new Javaer("張三")); //加入這句
task.Start();
}
}
輸出和前面的Demo是一樣的：
開發微信支付寶收款明細獲取工具 started ..
張三 writting java code...
現在，我們知道了一個事實，完成任務需要依賴特定的開發人員（NewTask類依賴Javaer類），開始時，NewTask類在構造時綁定開發人員，現在這種依賴可以在使用時按需要進行綁定。
這就是依賴注入
在上面的案例中，我們是通過Setter進行注入的，另外一種常用的注入方式是通過構造方法進行注入：
public NewTask(String name, Javaer javaer) {
this.name = name;
this.javaer = javaer; //構造方法中進行注入
}
這裏聯想一下，任務執行期間，任務執行者（本例中是張三）生病了，那麼就需要另外安排一名開發人員繼續任務的執行，怎麼辦呢？這個時候應該考慮的是Javaer這個對象的穩定性，如果開發人員這個對象穩定性非常高，我們可以考慮在NewTask的構造方法中進行注入，因爲開發人員這個對象非常穩定，不會出現中途換帥的情況，但事實並非如此，張三生病了，就得允許不中斷任務的情況下，重新指派另一名開發人員繼續進行開發，很顯然，在這個場景中，我們應該使用Setter注入，不需要重新New一個NewTask（也就是任務重新開始），直接使用Setter更換開發人員即可。
這裏還有一種注入方式是配置文件注入，這就要求注入的對象穩定性非常高，甚至高到大於服務的生命週期（比如數據庫連接）。
第二步：需求挖掘
我們知道，一個開發團隊往往是多種開發語言並存的，有些任務適合用Java來完成，有些適合用C#，還有些任務適合用Python，現在問題來了，這個NewTask類庫的使用者發現：任務只能指派給Javaer。
所以爲了更好的複用，我們的需求應該變成：任務既能指派給Javaer，也能指派給Pythoner和CSharper，以及其他任何以後可能加入的開發語言。
很自然的，我想到了使用接口:
package DependencyInjectionDemo;
public interface Coder {
void WriteCode();
}
修改原來的Javaer,實現Coder接口：
package DependencyInjectionDemo;
public class Javaer implements Coder {
private String name;
public Javaer(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public void WriteCode() {
System.out.println(this.name + " writting java code...");
}
}
Python開發人員實現Coder接口：
package DependencyInjectionDemo;
public class Pythoner implements Coder{
private String name;
public Pythoner(String name) {
this.name = name;
}
@Override
public void WriteCode() {
System.out.println(this.name + " writting python code...");
}
}
C# 開發人員實現Coder接口：
package DependencyInjectionDemo;
public class CSharper implements Coder {
private String name;
public CSharper(String name) {
this.name = name;
}
@Override
public void WriteCode() {
System.out.println(this.name + " writting c# code...");
}
}
修改任務類中的Javaer爲Coder：
public class NewTask {
private String name;
private Coder coder;
public NewTask(String name) {
this.name = name;
}
public void SetCoder(Coder coder) {
this.coder= coder;
}
public void Start() {
System.out.println(this.name + " started ..");
this.coder.WriteCode();
}
}
修改場景類：
package DependencyInjectionDemo;
public class DependencyInjectionDemo {
public static void main(String[] args) {
NewTask task = new NewTask("開發微信支付寶收款明細獲取工具");
task.SetCoder(new Javaer("張三"));
// 都是Coder，允許注入
// task.SetCoder(new Pythoner("李四"));
// task.SetCoder(new CSharper("王五"));
task.Start();
}
}
現在，我們可以指派任務給pythoner，CSharper和Javaer了，加入以後加入了Ruby或者Go語言開發人員，類庫的使用者只需要實現Coder接口，就可以把任務指派給新來的開發人員了，不需要修改NewTask代碼，實現了低耦合和可擴展性。
在講下面的內容之前，我們先來熟悉一個名詞：控制反轉，四個字，拆成兩個詞，一個是控制，一個是反轉。結合上面的例子，我們的NewTask開始的時候依賴開發人員，其在內部主動創建了開發人員對象，後來我們發現這樣造成了強依賴，於是就把NewTask的主動創建開發人員這個操作撤銷了，修改成了在外部實現開發人員實例並傳入到NewTask內部，NewTask現在只能被動的接收我們創建的開發人員對象，從主動到被動，控制實現了反轉。
概念
除了依賴注入(Dependency Injection, 簡稱DI)，還有另外一種方式是“依賴查找（Dependency Locate）”， 場景類需要服務類時，從一個獲取點主動取得指定的服務類。這種方式變被動接收注入爲主動獲取，使得場景類在需要時主動獲取服務類，如我們向一個統管全局的Factory傳入一個字符串，Factory返回給我一個相應服務類的實例。
不過，不論使用簡單工廠（Simple Factory）還是抽象工廠（Abstract Factory），都避免不了判斷服務類類型或工廠類型，這樣系統中總要有一個地方存在不符合OCP的if…else或switch…case結構，這種缺陷是Simple Factory和Abstract Factory以及依賴獲取本身無法消除的，而在某些支持反射的語言中（如Java和C#），通過將反射機制的引入徹底解決了這個問題。
反射與依賴注入
上面的例子中，假設我們再增加一個語言的分支（如Go）而且使用了工廠模式（簡單或抽象工廠），我們需要實現Coder接口，雖然符合開閉原則（對擴展開放，對修改關閉），但最終，我們還是要回到工廠方法內部，去增加一個swith或ifelse分支，以完善我們的判斷，這就破壞了開閉原則。依賴注入本身是沒有能力解決這個問題的，但語言本身的反射機制（Reflection）卻能從根本上解決這個問題。
現在的問題是，最終我們找到的這個對象，還是需要通過“new”操作來實例化，那麼，我們如何通過不修改代碼的方式，“new”出一個新的實例呢？
來試着實現一下：
package DependencyInjectionDemo;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
public class DependencyInjectionDemo {
private static String taskName; //任務
private static String coderName; //語言
private static String devName; //開發人員
public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
/*現在我可以把這些寫到配置文件中了*/
taskName = "新任務名稱";
coderName = "Pythoner";
devName = "小明";
NewTask task = new NewTask(taskName);
Coder coder = getCoder(coderName, devName);
task.SetCoder(coder);
/* 以前這麼寫 */
// task.SetCoder(new Pythoner("李四"));
// task.SetCoder(new CSharper("王五"));
task.Start();
}
/**
* 根據類名獲取類實例
* @param coderName
* @param name
* @return 類的實例對象
* @throws ClassNotFoundException
* @throws NoSuchMethodException
* @throws IllegalAccessException
* @throws InvocationTargetException
* @throws InstantiationException
*/
public static Coder getCoder(String coderName, String name) throws ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Constructor c = Class.forName("DependencyInjectionDemo."+coderName).getConstructor(String.class);
Coder coder = (Coder)c.newInstance(new Object[] {name});
return coder;
}
}
輸出：
新任務名稱 started ..
小明 writting python code...
以上代碼，實現了一個根據類名獲取實例的getCoder方法，該方法有兩個參數，一個是類名，另一個是Coder的構造參數name。在場景操作中，分別定義了任務名稱，語言，開發人員三個變量，現在假設這些變量完全是從配置文件中讀取的，那麼，當我們以後增加新的語言，增加新的開發人員時，只需要新增加一個Coder接口的實現，然後修改配置文件即可。真正實現了OCP原則。怎麼樣？是不是感覺自己很牛逼？
以下爲摘錄內容，來源:依賴注入那些事兒
IoC Container
說到依賴注入的話，就不能不提到IoC Container(IoC容器)，那麼到底什麼是IoC容器？我們還是先來看看它的出現背景。
我們知道，軟件開發領域有句著名的論斷：不要重複發明輪子！因爲軟件開發講求複用，所以，對於應用頻繁的需求，總是有人設計各種通用框架和類庫以減輕人們的開發負擔。例如，數據持久化是非常頻繁的需求，於是各種ORM框架應運而生；再如，對MVC的需求催生了Struts等一批用來實現MVC的框架。
隨着面向對象分析與設計的發展和成熟，OOA&D被越來越廣泛應用於各種項目中，然而，我們知道，用OO就不可能不用多態性，用多態性就不可能不用依賴注入，所以，依賴注入變成了非常頻繁的需求，而如果全部手工完成，不但負擔太重，而且還容易出錯。再加上反射機制的發明，於是，自然有人開始設計開發各種用於依賴注入的專用框架。這些專門用於實現依賴注入功能的組件或框架，就是IoC Container。
從這點看，IoC Container的出現有其歷史必然性。目前，最著名的IoC也許就是Java平臺上的Spring框架的IoC組件，而.NET平臺上也有Spring.NET和Unity等。
IoC Container 的分類
前面曾經討論了三種依賴注入方式，但是，想通過方式對IoC Container進行分類很困難，因爲現在IoC Container都設計很完善，幾乎支持所有依賴注入方式。不過，根據不同框架的特性和慣用法，還是可以講IoC Container分爲兩個大類。
-
重量級IoC Container
Spring和Spring.NET是重量級IoC Container的例子。一般來說，這種IoC Container穩定性有餘而活性不足，適合進行低活多態性的依賴注入。
所謂重量級IoC Container，是指一般用外部配置文件（一般是XML）作爲依賴源，並託管整個系統各個類的實例化的IoC Container。這種IoC Container，一般是承接了整個系統幾乎所有多態性的依賴注入工作，並承接了所有服務類的實例化工作，而且這些實例化依賴於一個外部配置文件，這種IoC Container，很像通過一個文件，定義整個系統多態結構，視野宏大，想要很好駕馭這種IoC Container，需要一定的架構設計能力和豐富的實踐經驗。 -
輕量級IoC Container
還有一種IoC Container，一般不依賴外部配置文件，而主要使用傳參的Setter或Construtor注入，這種IoC Container叫做輕量級IoC Container。這種框架很靈活，使用方便，但往往不穩定，而且依賴點都是程序中的字符串參數，所以，不適合需要大規模替換和相對穩定的低活多態性，而對於高活多態性，有很好的效果。
Unity是一個典型的輕量級IoC Container。
參考文獻