對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 is special because it has wheels.”

我想對這一概念執行 一個個人的闡述，以方便我的理解。控制反轉，從字面意思來看， 就是控制權由被動變主動又變為被動，或被動變主動又變為被動。從這個角度來說，IOC就變得非常容易理解了。 　
舉個例子：你的主管要求你做一件事情，這個時候就存在這么多個 流程 ,主管命令你做事情（這個時候主動權在主管，你是被動的） 　　
你接到命令做事情（這個時候主題是你，你是主動的，控制權在你手里） 你完成事情（這個時候主題依然是你，控制權在你手里） 　　
報告主管做完事情（主動權又叫交到主管手里了）

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

舉個代碼的例子：
假如有Class A，Class B，在A內部會原始化一個B，調用B的一個要領

假如在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好像他們是緊密連接在一塊的。