1?IoC理論的背景
??? 我們都知道在面向對象的應用中，軟件系統都是由N個對象組成的，它們通過彼此的合作，最終實現業務邏輯。

?
圖1：耦合在一起的對象

??? 如果我們打開機械式手表的后蓋，就會看到與上面類似的情形，各個齒輪分別帶動時針、分針和秒針順時針旋轉，從而在表盤上產生正確的時間。上圖畫的就是這樣的一個齒輪組，它擁有多個獨立的齒輪，這些齒輪相互嚙合在一起，協同工作，來共同完成某項任務。我們可以看到，在齒輪組中，如果有一個齒輪出了問題，就可能會影響到整個齒輪組的運轉。

??? 齒輪組中各個齒輪之間的嚙合關系,與軟件系統中對象與對象之間的耦合關系，非常類似。對象之間的耦合關系是必要的，是協同工作的基礎，當然也是無法避免的，否則無法保證系統整體的正常運轉。目前，很多工業級的應用越來越龐大，對象之間的依賴關系也越來越復雜，就會出現對象之間的多重依賴性關系，因此，架構師和設計師對系統進行分析和設計將面臨很大的挑戰。對象之間耦合度過高的系統，必然會出現牽一發而動全身的情形。

?

?
圖2：對象之間復雜的依賴關系

??? 耦合關系不僅會出現在對象與對象之間，也會出現在軟件系統的各模塊之間，以及軟件系統和硬件系統之間。如何降低系統之間、模塊之間和對象之間的耦合度，是軟件工程永遠追求的目標之一。
??? 所以有人就提出來IOC理論，用來實現對象之間的“解耦”，目前已被廣泛應用于很多項目中。

2?什么是控制反轉(IoC)
??? IoC是Inversion of Control的縮寫，多數書籍翻譯成“控制反轉”，還有些書籍翻譯成為“控制反向”或者“控制倒置”，這些都大同小異，我個人覺得這個翻譯有待商榷，容易引起歧義，是不是翻譯為 “控制轉移”會更好一些。
??? 1996年，Michael Mattson在一篇有關探討面向對象框架的文章中，首先提出了IoC 這個概念。對于面向對象設計及編程的基本思想，前面我們已經講了很多了，不再贅述，讀者可以參考我前面的文章，簡單來說就是把復雜系統分解成相互合作的對象，這些對象類的內部實現是透明的，從而降低了解決問題的復雜度，而且可以靈活地被重用和擴展。IoC理論提出的觀點大體是這樣的：借助于“第三方”實現具有依賴關系的對象之間的解耦，如下圖：

?

?圖3：IoC解耦示意圖

??? 大家看到了吧，由于引進了中間的“第三方”，也就是IoC容器，使得A、B、C、D這4個對象沒有了耦合關系，齒輪之間的傳動全部依靠“第三方”了，所有對象的控制權全部上繳給“第三方”，這就是“控制反轉”說法的由來，意思就是各個對象的控制權都被轉移給“第三方”了。
??? 從另一個角度來看，作為“第三方”的IoC容器成了整個系統的關鍵核心，它起到了一種類似“粘合劑”的作用，把系統中的所有對象粘合在一起發揮作用，如果沒有這個“粘合劑”，對象與對象之間會彼此失去聯系，這就是所謂的Ioc容器被稱為“粘合劑”的原因。
??? 我們再把上圖中間的Ioc容器拿掉后，整個系統變為這樣的情形：
?

圖4：拿掉IoC容器后的系統

??? 拿掉IoC容器后，我們看到的就是系統開發所需要完成的全部內容，這時候，A、B、C、D這4個對象之間已經沒有了耦合關系，彼此毫不影響，所以當你在實現Class A的時候，根本不用再考慮B、C和D了，系統對象之間的依賴已經降低到了最低程度。至于IoC容器，你可以到開源組織的網站上找一找，里面有很多比較成熟而且Free的，使用起來非常簡便。
如果真能實現控制反轉，對于系統開發而言，這將是一件多么美好的事情！

?

3?什么是依賴注入(DI)
??? 我們先看一些生活中的例子，幫助你理解依賴注入(DI)：

3.1?主機和內置硬盤
??? 我們平時所用的電腦，它的硬盤安裝在主機里面，從電腦的外部，我們是看不見硬盤的。所以，我們通常認為，電腦的所有部件是融為一體的。
?

圖5：主機和內置硬盤

??? 對于一體機而言，一旦出現了問題，我們可能無法準確地判斷到底是什么零部件出現了問題，有可能是CPU壞了，也有可能是主板燒了，還有可能是內存松動了。還有的時候，比如，電腦硬盤出現了問題，可能導致整臺電腦都無法使用。從這個例子，我們可以看到部件之間“緊密耦合”的產生的問題：無法準確的定位和診斷故障所在。這種情形，在軟件工程的理論中，稱之為可理解性和可測試性差。

??? 如果你想修理電腦的硬盤，那么在修理過程中就必須小心翼翼，不要把其它的部件再搞壞了，比如不慎把內存給碰松動了，硬盤固然是修好了，但整臺電腦仍然無法使用。這種情形，在軟件工程的理論中，稱之為可修改性差。
可理解性、可測試性、可修改性組成了系統的可維護性，一體機的可維護性就表現得比較差。

?

3.2?主機和USB設備
??? 大家對USB接口和設備應該都很熟悉。自從有了USB接口，給我們使用電腦帶來了很大的方便，現在有很多的外部設備都支持USB接口。
?

圖6：主機和USB設備

?

??? 從軟件工程角度，我們分析一下USB帶來的好處：
1、USB設備作為主機的外部設備，在插入主機之前，與主機沒有任何的關系，兩者都可獨立進行測試，無論兩者中的任何一方出現什么的問題，都不會影響另一方的運行，所以可維護性比較好。
2、同一個USB設備可以插接到不同的支持USB的任何主機，也就是USB設備可以被重復利用，所以可復用性比較好。
3、支持熱插拔，只要是支持USB接口的設備都可以接入，所以可擴展性比較好，非常靈活。

3.3?依賴注入
??? 2004年，Martin Fowler從另一個角度來思考這個問題，提出了“哪些方面的控制被反轉了？”這樣一個問題，并給出了答案：“依賴對象的獲得被反轉”。于是，他給“控制反轉”取了一個他認為更合適的名字叫做“依賴注入（Dependency Injection）”。他的這個答案，實際上點明了實現IoC理論的解決方法。所謂依賴注入，就是由IoC容器在運行期間，動態地將某種依賴關系注入到對象之中。

??? 依賴注入(DI)和控制反轉(IoC)是從不同的角度的描述的同一件事情，都是指通過引入第三方，即IoC容器，實現軟件系統中對象之間的解耦。

??? 控制反轉能夠帶給系統開發的好處，與USB機制帶來的好處基本類似，而且依賴注入的實現跟USB機制也完全一樣。USB機制是現實中依賴注入的很好的案例。我們用一個實際的例子，分析一下USB機制：

任務：主機通過USB接口讀取一個文件。
思路：首先，必須制定一個USB接口標準，主機對USB設備的訪問嚴格按照USB接口標準，USB設備提供的功能也必須符合USB接口標準。
??? 當主機需要獲取一個文件的時候，它直接去讀取USB接口，根本不會關心USB接口上連接的是什么設備。
如果我給主機連接上一個U盤，那么主機就從U盤上讀取文件；如果我給主機連接上一個外接硬盤，那么主機就從外接硬盤上讀取文件。選取何種外部設備的權力由我說了算，也就是控制權歸我。
至此,依賴注入的思路已經非常清楚：當主機需要讀取文件的時候，我就把它所要依賴的外部設備，挑出來一個，幫他掛接上。這個過程就是一個被依賴的對象在系統運行時被注入另外一個對象內部的過程。在這個過程中，我就起到了IoC容器的作用。

??? 我們再把依賴注入應用到軟件工程中：
??? Class A依賴于Class B,當Class A需要用到Class B的時候，IoC容器就會立刻創建一個Class B送給Class A使用。IoC容器就是一個類制造工廠，你需要什么，直接來拿，直接用就可以了，而不需要去關心你所用的東西是如何制成的，也不用關心最后是怎么被銷毀的，這一切全由IoC容器包辦。

?

? 4?實現IoC容器

?----------------------------------------------------

后記：之所以突然跳躍到39，是因為有的同學基礎比較好，已經沒有必要閱讀有關面向對象、設計模式以及軟件工程的基本理論，那么可以從這里開始閱讀。基礎需要繼續補全的同學，可以從4繼續看，我會定期在兩個方向進行更新。框架理論，是架構師知識體系中非常重要的部分，我會逐步結合實例，把常見的一些框架方面的知識與大家共享。

轉載于:https://www.cnblogs.com/encounter/archive/2009/03/08/2189049.html

總結

以上是生活随笔為你收集整理的架构师之路(5)---IoC框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。