對IOC的解釋為：“Inversion of control is a common characteristic of frameworks， so saying that these lightweight containers are special because they use inversion of control is like saying my car

　　我想對這一概念執行 一個個人的闡述，以方便我的理解。控制反轉，從字面意思來看， 就是控制權由被動變主動又變為被動，或被動變主動又變為被動。從這個角度來說，IOC就變得非常容易理解了。

　　舉個例子：你的主管要求你做一件事情，這個時候就存在這么多個 流程 ,主管命令你做事情(這個時候主動權在主管，你是被動的)

　　你接到命令做事情(這個時候主題是你，你是主動的，控制權在你手里) 你完成事情(這個時候主題依然是你，控制權在你手里)

　　報告主管做完事情(主動權又叫交到主管手里了)

　　上面的整個流程 就完成了一次IOC，從上面可以看出，IOC的基本思想是控制權的轉換流程 。

　　舉個代碼的例子：

　　假如有Class A，Class B，在A內部會原始化一個B，調用B的一個要領

　　DoMethod public Class B

　　{

　　public void DoMethod()

　　{

　　/// do somthing;

　　}

　　}

　　public Class A

　　{

　　public void Excute()

　　{

　　B b = new B();

　　b.DoMethod();

　　}

　　}

　　假如在Main函數中如下執行： 　　A a = new A(); 　　a.Excute();

　　從這兩行代碼來看，事實上也存在一個IOC的流程 ，a——>b——>a，理解的關鍵點就在在A的內部調用Excute的時候， 要領 b.DoMethod的執行。 　理解了IOC，我們再看一下DI， 從上面A調用B我們可以看出， 在原始化一個A的實例時，也必須實例化一個B，也就是說如果沒有B或者B出了疑問 ， A就不能 實例化，這就產生了一種依賴，就是A依賴B， 這種依賴從設計的角度來說就是耦合，顯然它是不能 滿足高內聚低耦合的要求的。這個時候就須要 解耦， 當然解耦有很多種要領 ， 而DI就是其中一種。不管任何一種解耦要領 ，都不是說使A和B完全沒有聯系 ， 而是把這種聯系 的實現變得隱晦，不那么直接，但是又很容易實現， 而且易于擴展，不像上面的代碼那樣，直接new一個B出來。那為什么我們總是把IOC和DI聯系到一起呢? 是因為DI的基本思想就是IOC，而體現IOC 思想的要領 還有另外一個，那就是Service Locator，這個要領 好像涉及到的很少。其實這些都是從java里面衍生出來的，雖然本人已經好幾年沒用java，里面Spring這些都會用到IOC、DI好像他們是緊密連接在一塊的。