淺談IOC-說清楚IOC是什么

說本文旨在用語言(非代碼)說清楚IOC到底是什么沒有什高深的技術(shù)園中的老牛、大蝦們看到這里可以繞行了，以免浪費(fèi)您寶貴的時(shí)間。IOC這個(gè)東西早就想寫了，但是出于對(duì)文章權(quán)威性的考(不能誤人子弟--!)本文主要內(nèi)容來源于最近LZ看的一些國內(nèi)外的關(guān)于的博文博問所有引用到的文章，在參考博均已注明。理論背景我們知道在面向?qū)ο笤O(shè)計(jì)的軟件系統(tǒng)中，它的底層都是由個(gè)對(duì)象構(gòu)成的，各個(gè)對(duì)象之間通過相互合作，最終實(shí)現(xiàn)系統(tǒng)地業(yè)務(wù)邏輯[1]。圖1軟件系統(tǒng)中耦合的對(duì)象如果我們打開機(jī)械式手表的后蓋就會(huì)看到與上面類似的情形各個(gè)齒輪分別帶動(dòng)時(shí)針分針和秒針順時(shí)針旋轉(zhuǎn)從而在表盤上產(chǎn)生正確的時(shí)間圖1描述的就是這樣的一個(gè)齒輪組擁有多個(gè)獨(dú)立的齒輪些齒輪相互嚙合在一起，協(xié)同工作，共同完成某項(xiàng)任務(wù)。我們可以看到，在這樣的齒輪組中，如果有一個(gè)齒輪出了問題，就可能會(huì)影響到整個(gè)齒輪組的正常運(yùn)轉(zhuǎn)。齒輪組中齒輪之間的嚙合關(guān)系與軟件系統(tǒng)中對(duì)象之間的耦合關(guān)系非常相似。對(duì)象之間的耦合關(guān)系是無法避免的，也是必要的，這是協(xié)同工作的基礎(chǔ)?，F(xiàn)在，伴隨著工業(yè)級(jí)應(yīng)用的規(guī)模越來越龐大，對(duì)象之間的依賴關(guān)系也越來越復(fù)雜，經(jīng)常會(huì)出現(xiàn)對(duì)象之間的多重依賴性關(guān)系因此架構(gòu)師和設(shè)計(jì)師對(duì)于系統(tǒng)的分析和設(shè)計(jì)將面臨更大的挑戰(zhàn)對(duì)象之間耦合度過高的系統(tǒng)必然會(huì)出現(xiàn)牽一發(fā)而動(dòng)全身的情形。

圖2對(duì)象之間的依賴關(guān)系耦合關(guān)系不僅會(huì)出現(xiàn)在對(duì)象與對(duì)象之間，也會(huì)出現(xiàn)在軟件系統(tǒng)的各模塊之間以及軟件系統(tǒng)和硬件系統(tǒng)之間如何降低系統(tǒng)之間模塊之間和對(duì)象之間的耦合度是軟件工程永遠(yuǎn)追求的目標(biāo)之一為了解決對(duì)象之間的耦合度過高的問題件專家1996年提出了IOC理論實(shí)現(xiàn)對(duì)象之間的“解耦”，目前這個(gè)理論已經(jīng)被成功地應(yīng)用到實(shí)踐當(dāng)中。什是IOCofControl的縮寫，多數(shù)書籍翻譯成“控制反轉(zhuǎn)”。1996，Michael一篇有關(guān)探討面向?qū)ο罂蚣艿奈恼轮校紫忍岢隽薎OC這個(gè)概念。對(duì)于面向?qū)ο笤O(shè)計(jì)及編程的基本思想，前面我們已經(jīng)講了很多了不再贅述簡單來說就是把復(fù)雜系統(tǒng)分解成相互合作的對(duì)象這些對(duì)象類通過封裝以后內(nèi)部實(shí)現(xiàn)對(duì)外部是透明的從而降低了解決問題的復(fù)雜度而且可以靈活地被重用和擴(kuò)展。IOC論提出的觀點(diǎn)大體是這樣的借助于第三方”實(shí)現(xiàn)具有依賴關(guān)系的對(duì)象之間的解耦。如下圖：

圖3IOC耦過程大家看到了吧于引進(jìn)了中間位置的“第三方”就是IOC容器得A、B、C、這個(gè)對(duì)象沒有了耦合關(guān)系，齒輪之間的傳動(dòng)全部依靠第三方”了，全部對(duì)象的控制權(quán)全部上繳給“第三方IOC容器，所以IOC容器成了整個(gè)系統(tǒng)的關(guān)鍵核心它起到了一種類似“粘合劑的作用把系統(tǒng)中的所有對(duì)象粘合在一起發(fā)揮作用，如果沒有這“粘合劑，對(duì)象與對(duì)象之間會(huì)彼此失去聯(lián)系，這就是有人把IOC容器比喻成“粘合劑的由來。我們?cè)賮碜鰝€(gè)試驗(yàn)：把上圖中間的IOC器拿掉，然后再來看看這套系統(tǒng)：圖4拿掉IOC器后的系統(tǒng)我們現(xiàn)在看到的畫面就是我們要實(shí)現(xiàn)整個(gè)系統(tǒng)所需要完成的全部內(nèi)容這時(shí)候，ABCD這4對(duì)象之間已經(jīng)沒有了耦合關(guān)系，彼此毫無聯(lián)系，這樣的話，當(dāng)你在實(shí)現(xiàn)A的候，根本無須再去考慮、CD了，對(duì)象之間的依賴關(guān)系已經(jīng)降低到了最低程度。所以，如果真能實(shí)現(xiàn)IOC器，對(duì)于系統(tǒng)開發(fā)而言這將是一件多么美好的事情參與開發(fā)的每一成員只要實(shí)現(xiàn)自己的類就可以了，跟別人沒有任何關(guān)系！我們?cè)賮砜纯?，控制反轉(zhuǎn)(IOC)到底為什么要起這么個(gè)名字？我們來對(duì)比一下：軟件系統(tǒng)在沒有引入容器之前，如圖1所示，對(duì)象A依賴于對(duì)象B，那么對(duì)象A在初始化或者運(yùn)行到某一點(diǎn)的時(shí)候，自己必須主動(dòng)去創(chuàng)建對(duì)象者使用已經(jīng)創(chuàng)建的對(duì)象B。無論是創(chuàng)建還是使用對(duì)象B，控制權(quán)都在自己手上。軟件系統(tǒng)在引入容器之后，這種情形就完全改變了，如圖3示，由于IOC器的加入，對(duì)象A對(duì)象B之間失去了直接聯(lián)系，所，當(dāng)對(duì)象A運(yùn)

到需要對(duì)象B時(shí)候，容器會(huì)主動(dòng)創(chuàng)建一個(gè)對(duì)象B注入到對(duì)象A需要的地方。通過前后的對(duì)比我們不難看出來對(duì)象A獲依賴對(duì)象B的過程由主動(dòng)行為變?yōu)榱吮粍?dòng)行為，控制權(quán)顛倒過來了，這就是“控制反轉(zhuǎn)”這個(gè)名稱的由來。叫依賴注2004，MartinFowler探討了同一個(gè)問題既然IOC是控制反轉(zhuǎn)，那么到底是“哪些方面的控制被反轉(zhuǎn)了呢？”過詳細(xì)地分析和論證后得出了答案：“獲得依賴對(duì)象的過程被反轉(zhuǎn)了控制被反轉(zhuǎn)之后獲得依賴對(duì)象的過程由自身管理變?yōu)榱擞蒊OC容器主動(dòng)注入。于是，他給控制反轉(zhuǎn)”取了一個(gè)更合適的名字叫做“依賴注入（Injection”。他的這個(gè)答案，實(shí)際上給出了實(shí)現(xiàn)IOC方法：注入。謂依賴注入，就是由IOC容器在運(yùn)行期間，動(dòng)態(tài)地將某種依賴關(guān)系注入到對(duì)象之中。所以，依賴注入(和控制反轉(zhuǎn)(IOC)是從不同的角度的描述的同一件事情，就是指通過引入IOC容器，利用依賴關(guān)系注入的方式，實(shí)現(xiàn)對(duì)象之間解耦。學(xué)過IOC的可能都看過MartinFowler(馬2004post)這篇文章：ofContainerstheInjection。博客園的園友邢瑜琨)的文章：深度理解依賴注入（）[3]對(duì)老馬那篇經(jīng)典文章進(jìn)行了解讀。CSDN黃忠成的InsideObjectBuilder[4]也是不過他應(yīng)該來自臺(tái)灣省用的是繁體，看不管繁體中文的，可以看園中的呂震宇博友的簡體中文[轉(zhuǎn)]Block[5]。優(yōu)缺點(diǎn)Inmyexperience,thecontainerbroughtthefollowingo

theclassforsimpler(e.g.replaceamockwebtheinstance)

oo

retrievalforagivenclassis(e.g.aservicefromtheclasspathtotheJNDIinterceptorsisanddoneinacachitoaDAO)

oo

theprojecthasunifiedandconsistentcomponentmodellittwithfactoriesDAOthebrieferandisnotwithoutlookupcode(e.g.toJNDIInitialContext)

ooo

dependenciestoreplacewhenthey'rethroughacortomoretestingtestingleadstobetterquality,cohesion使用IOC框產(chǎn)品能夠給我們的開發(fā)過程帶來很大的好處，但是也要充分認(rèn)識(shí)引入IOC框架的缺點(diǎn)，做到心中有數(shù)，杜絕濫用框架[1]。第一、軟件系統(tǒng)中由于引入了第三方容器，生成對(duì)象的步驟變得有些復(fù)雜，本來是兩者之間的事情，又憑空多出一道手續(xù)，所以，我們?cè)趧傞_始使用IOC框的時(shí)候，會(huì)感覺系統(tǒng)變得不太直觀。所以，引入了一個(gè)全新的框架，就會(huì)增加團(tuán)隊(duì)成員學(xué)習(xí)和認(rèn)識(shí)的培訓(xùn)成本并且在以后的運(yùn)行維護(hù)中還得讓新加入者具備同樣的知識(shí)體系。第二由于IOC器生成對(duì)象是通過反射方式在運(yùn)行效率上有一定的損耗。如果你要追求運(yùn)行效率的話，就必須對(duì)此進(jìn)行權(quán)衡。第三、具體到IOC框架產(chǎn)品(比如：來講，需要進(jìn)行大量的配制工作，比較繁瑣，對(duì)于一些小的項(xiàng)目而言，客觀上也可能加大一些工作成本。第四、IOC框架產(chǎn)品本身的成熟度需要進(jìn)行評(píng)估，如果引入一個(gè)不成熟的C框架產(chǎn)品，那么會(huì)影響到整個(gè)項(xiàng)目，所以這也是一個(gè)隱性的風(fēng)險(xiǎn)。我們大體可以得出這樣的結(jié)論：一些工作量不大的項(xiàng)目或者產(chǎn)品，不太適合使用IOC框架產(chǎn)品。另外，如果團(tuán)隊(duì)成員的知識(shí)能力欠缺，對(duì)于IOC架產(chǎn)品缺乏深入的理解，也不要貿(mào)然引入。最后，特別強(qiáng)調(diào)運(yùn)行效率的項(xiàng)目或者產(chǎn)品，也不太適合引入IOC框架產(chǎn)品，像WEB2.0網(wǎng)站就是這種情況。

器的技術(shù)析IOC最基本的技術(shù)就是“反射(Reflection)編程，目Net、Java和P5語言均支持其中PHP5的技術(shù)書籍中有時(shí)候也被翻譯成“映射有關(guān)反射的概念和用法大家應(yīng)該都很清楚通俗來講就是根據(jù)給出的類（字符串方式來動(dòng)態(tài)地生成對(duì)象這種編程方式可以讓對(duì)象在生成時(shí)才決定到底是哪一種對(duì)象。反射的應(yīng)用是很廣泛的，很多的成熟的框架，比如Java中的、架，中NHibernate、框架都是把反射”做為最基本的技術(shù)手段。器的一些品Sun技術(shù)體系下的IOC容器有：輕量級(jí)的有、GuicePico、Avalon、HiveMind；重量級(jí)的有EJB；不輕不重的JBoss