在采用面向對象方法設計的軟體系統中，它的底層實作都是由n個對象組成的，所有的對象通過互相合作，最終實作系統的業務邏輯。
如果我們打開機械手表的後蓋，就會看到與上面類似的情景，各個齒輪分别帶動時針、分針和秒針順時針旋轉，進而在表盤上産生正确的時間。上圖描述的的就是這樣的一個齒輪組，他擁有多個獨立的齒輪，這些齒輪互相齧合在一起，協同工作，共同完成某項任務。我們可以看到，在這樣的齒輪組中，如果有一個齒輪出了問題，就可能會影響到整個齒輪組的正常運轉。
齒輪組中齒輪之間的齧合關系,與軟體系統中對象之間的耦合關系非常相似。對象之間的耦合關系是無法避免的，也是必要的，這是協同工作的基礎。
現在，伴随着工業級應用的規模越來越龐大，對象之間的依賴關系也越來越複雜，經常會出現對象之間的多重依賴性關系，對象之間耦合度過高的系統，必然會出現牽一發而動全身的情形。
耦合關系不僅會出現在對象與對象之間，也會出現在軟體系統的各子產品之間，以及軟體系統和硬體系統之間。如何降低系統之間、子產品之間和對象之間的耦合度，是軟體工程永遠追求的目标之一。為了解決對象之間的耦合度過高的問題，軟體專家michael mattson提出了ioc理論，用來實作對象之間的“解耦”
inversion of control，英文縮寫為ioc，不是什麼技術，而是一種設計思想。
簡單來說就是把複雜系統分解成互相合作的對象，這些對象類通過封裝以後，内部實作對外部是透明的，進而降低了解決問題的複雜度，而且可以靈活地被重用和擴充。ioc理論提出的觀點大體是這樣的：借助于“第三方”實作具有依賴關系的對象之間的解耦，如下圖：
大家看到了吧，由于引進了中間位置的“第三方”，也就是ioc容器，使得a、b、c、d這4個對象沒有了耦合關系，齒輪之間的傳動全部依靠“第三方”了，全部對象的控制權全部上繳給“第三方”ioc容器，是以，ioc容器成了整個系統的關鍵核心，它起到了一種類似“粘合劑”的作用，把系統中的所有對象粘合在一起發揮作用，如果沒有這個“粘合劑”，對象與對象之間會彼此失去聯系，這就是有人把ioc容器比喻成“粘合劑”的由來。
我們再來做個試驗：把上圖中間的ioc容器拿掉，然後再來看看這套系統：
我們現在看到的畫面，就是我們要實作整個系統所需要完成的全部内容。這時候，a、b、c、d這4個對象之間已經沒有了耦合關系，彼此毫無聯系，這樣的話，當你在實作a的時候，根本無須再去考慮b、c和d了，對象之間的依賴關系已經降低到了最低程度。是以，如果真能實作ioc容器，對于系統開發而言，這将是一件多麼美好的事情，參與開發的每一成員隻要實作自己的類就可以了，跟别人沒有任何關系！
然後我們再看一下為什麼ioc叫控制反轉？
1、沒有引入ioc之前，對象a依賴于對象b，那麼對象a在初始化或者運作到某一點的時候，a直接使用new關鍵字建立b的執行個體，程式高度耦合，效率低下，無論是建立還是使用b對象，控制權都在自己手上。 2、軟體系統在引入ioc容器之後，這種情形就完全改變了，由于ioc容器的加入，對象a與對象b之間失去了直接聯系，是以，當對象a運作到需要對象b的時候，ioc容器會主動建立一個對象b注入到對象a需要的地方。
通過對比發現，a在擷取對象b的過程中，有主動變為被動，控制權颠倒了過來，這就是控制反轉這個名稱的由來。
代碼中的具體實作在下一篇部落格中實作，敬請期待！