IOC是什麼

IoC是什嗎？Inversion of Control，即反轉控制，或許說為依賴注入更為合適。IoC就是IoC，不是什麼技術，與GoF一樣，是一種設計模式。

    Interface Driven Design介面驅動，介面驅動有很多好處，可以提供不同靈活的子類實現，增加代碼穩定和健壯性等等，但是介面一定是需要實現的，也就是如下語句遲早要執 行：AInterface a = new AInterfaceImp(); 這樣一來，耦合關係就產生了，如：    Class A{       AInterface a;       A(){}       aMethod(){          a = new AInterfaceImp();       }    }ClassA與AInterfaceImp就是依賴關係，如果想使用AInterface的另外一個實現就需要更改代碼了。當然我們可以建立一個Factory來根據條件產生想要的AInterface的具體實現，即：    InterfaceImplFactory{        AInterface create(Object condition){            if(condition = condA){                return new AInterfaceImpA();            }elseif(condition = condB){                return new AInterfaceImpB();            }else{                return new AInterfaceImp();            }        }    }表 面上是在一定程度上緩解了以上問題，但實質上這種代碼耦合并沒有改變。通過IoC模式可以徹底解決這種耦合，它把耦合從代碼中移出去，放到統一的XML文 件中，通過一個容器在需要的時候把這個依賴關係形成，即把需要的介面實現注入到需要它的類中，這可能就是“依賴注入”說法的來源了。    IOC模式，系統中通過引入實現了IOC模式的IOC容器，即可由IOC容器來管理對象的生命週期、依賴關係等，從而使得應用程式的配置和依賴性規範與實 際的應用程式代碼分開。其中一個特點就是通過文本的配件檔案進行應用程式組件間相互關係的配置，而不用重新修改並編譯具體的代碼。
    當前比較知名的IOC容器有：Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。
    在上面的幾個IOC容器中，輕量級的有Pico Container、Avalon、Spring、HiveMind等，超重量級的有EJB，而半輕半重的有容器有JBoss，Jdon等。
    可以把IoC模式看做是原廠模式的升華，可以把IoC看作是一個大工廠，只不過這個大工廠裡要產生的對象都是在XML檔案中給出定義的，然後利用Java 的“反射”編程，根據XML中給出的類名產生相應的對象。從實現來看，IoC是把以前在Factory 方法裡寫死的對象產生代碼，改變為由XML檔案來定義，也就是 把工廠和對象產生這兩者獨立分隔開來，目的就是提高靈活性和可維護性。
    IoC中最基本的Java技術就是“反射”編程。反射又是一個生澀的名詞，通俗的說反射就是根據給出的類名（字串）來產生對象。這種編程方式可以讓對象 在產生時才決定要產生哪一種對象。反射的應用是很廣泛的，象Hibernate、String中都是用“反射”做為最基本的技術手段。
    在過去，反射編程方式相對於正常的對象產生方式要慢10幾倍，這也許也是當時為什麼反射技術沒有普通應用開來的原因。但經SUN改良最佳化後，反射方式產生對象和通常對象產生方式，速度已經相差不大了（但依然有一倍以上的差距）。
    IoC最大的好處是什嗎？因為把對象產生放在了XML裡定義，所以當我們需要換一個實現子類將會變成很簡單（一般這樣的對象都是現實於某種介面的），只要修改XML就可以了，這樣我們甚至可以實現對象的熱插撥（有點象USB介面和SCIS硬碟了）。
    IoC最大的缺點是什嗎？（1）產生一個對象的步驟變複雜了（其實上操作上還是挺簡單的），對於不習慣這種方式的人，會覺得有些彆扭和不直觀。（2）對象 產生因為是使用反射編程，在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某對象的產生對效率要求特別高。（3） 缺少IDE重構作業的支援，如果在Eclipse要對類改名，那麼你還需要去XML檔案裏手工去改了，這似乎是所有XML方式的缺憾所在。 IOC實現初探

   IOC關注服務(或應用程式組件)是如何定義的以及他們應該如何定位他們依賴的其它服務。通常，通過一個容器或定位架構來獲得定義和定位的分離，容器或定位架構負責：

• 儲存可用服務的集合
• 提供一種方式將各種組件與它們依賴的服務綁定在一起
• 為應用程式代碼提供一種方式來請求已配置的對象(例如，一個所有依賴都滿足的對象)， 這種方式可以確保該對象需要的所有相關的服務都可用。

現有的架構實際上使用以下三種基本技術的架構執行服務和組件間的綁定:

• 類型1 (基於介面): 可服務的對象需要實現一個專門的介面，該介面提供了一個對象，可以從用這個對象尋找依賴(其它服務)。早期的容器Excalibur使用這種模式。
• 類型2 (基於setter): 通過JavaBean的屬性(setter方法)為可服務物件指定服務。HiveMind和Spring採用這種方式。
• 類型3 (基於建構函式): 通過建構函式的參數為可服務物件指定服務。PicoContainer只使用這種方式。HiveMind和Spring也使用這種方式。

====================================================================================

IoC就是Inversion of Control，控制反轉。在Java開發中，IoC意味著將你設計好的類交給系統去控制，而不是在你的類內部控制。這稱為控制反轉。

下面我們以幾個例子來說明什麼是IoC

假設我們要設計一個Girl和一個Boy類，其中Girl有kiss方法，即Girl想要Kiss一個Boy。那麼，我們的問題是，Girl如何能夠認識這個Boy？

在我們中國，常見的MM與GG的認識方式有以下幾種
1 青梅竹馬； 2 親友介紹； 3 父母包辦
那麼哪一種才是最好呢？

青梅竹馬：Girl從小就知道自己的Boy。

public class Girl {
void kiss(){
Boy boy = new Boy();
}
}

然而從開始就建立的Boy缺點就是無法在更換。並且要負責Boy的整個生命週期。如果我們的Girl想要換一個怎麼辦？（嚴重不支援Girl經常更換Boy,#_#）

親友介紹：由中間人負責提供Boy來見面

public class Girl {
void kiss(){
Boy boy = BoyFactory.createBoy();
}
}

親友介紹，固然是好。如果不滿意，儘管另外換一個好了。但是，親友BoyFactory經常是以Singleton的形式出現，不然就是，存在於 Globals，無處不在，無處不能。實在是太繁瑣了一點，不夠靈活。我為什麼一定要這個親友摻和進來呢？為什麼一定要付給她介紹費呢？萬一最好的朋友愛 上了我的男朋友呢？

父母包辦：一切交給父母，自己不用費吹灰之力，只需要等著Kiss就好了。

public class Girl {
void kiss(Boy boy){
// kiss boy
boy.kiss();
}
}

Well，這是對Girl最好的方法，只要想辦法賄賂了Girl的父母，並把Boy交給他。那麼我們就可以輕鬆的和Girl來Kiss了。看來幾千年傳統的父母之命還真是有用哦。至少Boy和Girl不用自己瞎忙乎了。

這就是IOC，將對象的建立和擷取提取到外部。由外部容器提供需要的組件。

我們知道好萊塢原則：“Do not call us, we will call you.” 意思就是，You, girlie, do not call the boy. We will feed you a boy。

我們還應該知道依賴倒轉原則即 Dependence Inversion Princinple，DIP

Eric Gamma說，要面向抽象編程。面向介面編程是物件導向的核心。

組件應該分為兩部分，即 Service, 所提供功能的聲明 Implementation, Service的實現

好處是：多實現可以任意切換，防止 “everything depends on everything” 問題．即具體依賴於具體。

所以，我們的Boy應該是實現Kissable介面。這樣一旦Girl不想kiss可惡的Boy的話，還可以kiss可愛的kitten和慈祥的grandmother。
二、IOC的type

IoC的Type指的是Girl得到Boy的幾種不同方式。我們逐一來說明。

IOC type 0：不用IOC
public class Girl implements Servicable {
private Kissable kissable;
public Girl() {
kissable = new Boy();
}
public void kissYourKissable() {
kissable.kiss();
}
}

Girl自己建立自己的Boy，很難更換，很難共用給別人，只能單獨使用，並負責完全的生命週期。

IOC type 1，先看代碼：代碼

public class Girl implements Servicable {

Kissable kissable;

public void service(ServiceManager mgr) {
kissable = (Kissable) mgr.lookup(“kissable”);
}

public void kissYourKissable() {
kissable.kiss();
}

}

這種情況出現於Avalon Framework。一個組件實現了Servicable介面，就必須實現service方法，並傳入一個ServiceManager。其中會含有需要的其它組件。只需要在service方法中初始化需要的Boy。

另外，J2EE中從Context取得對象也屬於type 1。它依賴於設定檔。

IOC type 2：

public class Girl {

private Kissable kissable;

public void setKissable(Kissable kissable) {
this.kissable = kissable;
}

public void kissYourKissable() {
kissable.kiss();
}

}

Type 2出現於Spring Framework，是通過JavaBean的set方法來將需要的Boy傳遞給Girl。它必須依賴於設定檔。

IOC type 3:

public class Girl {

private Kissable kissable;

public Girl(Kissable kissable) {
this.kissable = kissable;
}

public void kissYourKissable() {
kissable.kiss();
}

}

這就是PicoContainer的組件 。通過建構函式傳遞Boy給Girl

PicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(Boy.class);
container.registerComponentImplementation(Girl.class);
Girl girl = (Girl) container.getComponentInstance(Girl.class);
girl.kissYourKissable();

參考資料

1 http://www.picocontainer.org/presentations/JavaPolis2003.ppt
http://www.picocontainer.org/presentations/JavaPolis2003.pdf

2 DIP， Robert C Martin, Bob大叔的優秀論文
http://www.objectmentor.com/resources/articles/dip.pdf

3 Dependency Injection 依賴注射，Matrin Fowler對DIP的擴充
http://www.martinfowler.com/articles/injection.html

4 IOC架構

PicoContainer 優秀的IOC架構
http://picocontainer.org/

Avalon
http://avalon.apache.org/

Spring Framework
http://www.springframework.org/

HiveMind
http://jakarta.apache.org/commons/hivemind