其實(shí)
IOC模式并不是什么新的東西，它是一種很普遍的概念（或者說結(jié)構(gòu)），GoF中的Template Method 就是IOC的結(jié)構(gòu)。顧名思義，IOC即控制反轉(zhuǎn)。著名的好萊塢原則：“Don’t Call us, We will call you”，以及Robert C. Martin在其敏捷軟件開發(fā)中所描述的依賴倒置原則（Dependency Inversion Principle, DIP）都是這一思想的體現(xiàn)。Dependency Injection是Martin Flower對(duì)IOC模式的一種擴(kuò)展的解釋，下面我們從一個(gè)簡(jiǎn)單的實(shí)例開始。
考慮一個(gè)Button來控制Lamp的開和關(guān)。
如下的類圖，并寫下了代碼。
public class Button {
private Lamp lnkLamp;
public void poll() {
lnkLamp.Turnon();
}
}
但是馬上發(fā)現(xiàn)這個(gè)設(shè)計(jì)的問題，Button類直接依賴于Lamp類，這個(gè)依賴關(guān)系意味著當(dāng)Lamp類修改時(shí)，Button類會(huì)受到影響。此外，想重用Button類來控制類似與Lamp的另外一個(gè)對(duì)象則是不可能的。即Button控制Lamp，并且只能控制Lamp。
顯然，我違反了“高層模塊不應(yīng)該依賴于底層模塊，兩者都應(yīng)該依賴于抽象；抽象不應(yīng)該依賴于具體實(shí)現(xiàn)，細(xì)節(jié)應(yīng)該依賴于抽象” 這一原則（DIP原則）。
考慮到上述問題，自然地想到應(yīng)該抽象出一個(gè)接口，來消除Button對(duì)Lamp的依賴，于是設(shè)計(jì)如下：
這樣，我們倒置了Button對(duì)Lamp的依賴關(guān)系，使得Lamp依賴于SwitchableDevice接口，SwitchableDevice并沒有依賴于Button類，任何知道如何操縱該接口的對(duì)象都可以控制Lamp。同時(shí)Button不只是可以控制Lamp，還可以控制同樣實(shí)現(xiàn)SwitchableDevice接口的如Computer、Cell Phone等等。回頭想想，這種做法好像似曾相識(shí)，拍拍腦袋，哦！這不是GoF策略（Strategy）模式嗎？！正是，不經(jīng)意間我就應(yīng)用了設(shè)計(jì)模式（有點(diǎn)得意哦~~~~）。
現(xiàn)在再來考慮一個(gè)問題，剛才的做法雖然倒置了依賴關(guān)系，但是如果將Button作為一個(gè)應(yīng)用程序來控制Lamp或者同樣實(shí)現(xiàn)SwitchableDevice的Computer、Cell Phone等，則代碼可能如下：
public class Button {
private SwitchableDevice lnkLamp;
public Button(){
lnkLamp= new Lamp();
}
…
}
也就是說Button和Lamp之間仍然存在《creates》這樣的依賴關(guān)系。
為了解除這種依賴關(guān)系，首先看GoF能作些什么。顯然，這個(gè)地方應(yīng)該用Factory模式，將對(duì)象的創(chuàng)建交給Factory Class來處理，這樣雖然解開了Lamp組件與我們應(yīng)用程序Button之間的耦合關(guān)系，但是組件的創(chuàng)建仍然是顯式的（explicitly），在組件更改時(shí)仍需要重新編譯。
另外，通過一個(gè)ServiceLocator去look up實(shí)現(xiàn)類也是一種解除耦合的辦法，看到這兒，你不禁會(huì)想EJB不就是這么實(shí)現(xiàn)的嘛，U are Right! Rod Johnson 在其大作J2EE without EJB中稱這種方式為Dependency Look up，但這種方式也有其弊端，比如無(wú)法脫離容器環(huán)境，以及不利于Unit test等。
“Don’t Call us, We will Call you”，這個(gè)原則啟示我們應(yīng)該換一個(gè)思路，不應(yīng)該在應(yīng)用類中創(chuàng)建具體對(duì)象的實(shí)例，而是應(yīng)該將具體對(duì)象實(shí)例的創(chuàng)建插入(plug)或者說注射（inject）到應(yīng)用類中，這大概是依賴注射名稱的由來吧。
這種實(shí)現(xiàn)方式需要在應(yīng)用類以及調(diào)用組件之間建立一個(gè)assembler來解除兩者之間的依賴，看起來與前面的方式?jīng)]有太大區(qū)別，來看一下結(jié)構(gòu)：
仔細(xì)查看會(huì)發(fā)現(xiàn)還是有比較大的不同，依賴關(guān)系是相反的，也就是說這個(gè)過程中依然倒置了依賴關(guān)系。Lamp通過Assembler將其創(chuàng)建過程注射到了Button中，從而消除了兩者之間的耦合，增加了靈活性。
下面我們看一下具體的實(shí)現(xiàn)，在PicoContainer以及Spring中有著其不同的實(shí)現(xiàn)，分別代表了兩種類型的Dependency Injection, 即Constructor Injection 和Setter Injection。
private MutablePicoContainer configureContainer() {
MutablePicoContainer pico = new DefaultPicoContainer();
pico.registerComponentImplementation(SwitchableDevice.class, Lamp.class);
pico.registerComponentImplementation(Button.class);
return pico;
}
然后可以通過MutablePicoContainer的getComponentImplementation方法獲得實(shí)現(xiàn)類，調(diào)用其poll方法控制Lamp的開關(guān)，這樣一來，兩者之間的耦合通過PicoContainer提供的Assembler完全消除了。
Spring則通過一個(gè)XML格式的配置文件，將兩者聯(lián)系起來，使用時(shí)，通過ApplicationContext獲得Button Bean，再調(diào)用其方法實(shí)現(xiàn)，同樣也消除了耦合關(guān)系