IoC是什么？Inversion of Control，即反轉(zhuǎn)控制，或許說(shuō)為依賴(lài)注入更為合適。IoC就是IoC，不是什么技術(shù)，與GoF一樣，是一種設(shè)計(jì)模式。

Interface Driven Design接口驅(qū)動(dòng)，接口驅(qū)動(dòng)有很多好處，可以提供不同靈活的子類(lèi)實(shí)現(xiàn)，增加代碼穩(wěn)定和健壯性等等，但是接口一定是需要實(shí)現(xiàn)的，也就是如下語(yǔ)句遲早要執(zhí) 行：AInterface a = new AInterfaceImp(); 這樣一來(lái)，耦合關(guān)系就產(chǎn)生了，如： Class A{ AInterface a; A(){} aMethod(){ a = new AInterfaceImp(); } } ClassA與AInterfaceImp就是依賴(lài)關(guān)系，如果想使用AInterface的另外一個(gè)實(shí)現(xiàn)就需要更改代碼了。當(dāng)然我們可以建立一個(gè)Factory來(lái)根據(jù)條件生成想要的AInterface的具體實(shí)現(xiàn)，即： InterfaceImplFactory{ AInterface create(Object condition){ if(condition = condA){ return new AInterfaceImpA(); }elseif(condition = condB){ return new AInterfaceImpB(); }else{ return new AInterfaceImp(); } } } 表 面上是在一定程度上緩解了以上問(wèn)題，但實(shí)質(zhì)上這種代碼耦合并沒(méi)有改變。通過(guò)IoC模式可以徹底解決這種耦合，它把耦合從代碼中移出去，放到統(tǒng)一的XML文 件中，通過(guò)一個(gè)容器在需要的時(shí)候把這個(gè)依賴(lài)關(guān)系形成，即把需要的接口實(shí)現(xiàn)注入到需要它的類(lèi)中，這可能就是“依賴(lài)注入”說(shuō)法的來(lái)源了。 IOC模式，系統(tǒng)中通過(guò)引入實(shí)現(xiàn)了IOC模式的IOC容器，即可由IOC容器來(lái)管理對(duì)象的生命周期、依賴(lài)關(guān)系等，從而使得應(yīng)用程序的配置和依賴(lài)性規(guī)范與實(shí) 際的應(yīng)用程序代碼分開(kāi)。其中一個(gè)特點(diǎn)就是通過(guò)文本的配件文件進(jìn)行應(yīng)用程序組件間相互關(guān)系的配置，而不用重新修改并編譯具體的代碼。
??? 當(dāng)前比較知名的IOC容器有：Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。
??? 在上面的幾個(gè)IOC容器中，輕量級(jí)的有Pico Container、Avalon、Spring、HiveMind等，超重量級(jí)的有EJB，而半輕半重的有容器有JBoss，Jdon等。
??? 可以把IoC模式看做是工廠模式的升華，可以把IoC看作是一個(gè)大工廠，只不過(guò)這個(gè)大工廠里要生成的對(duì)象都是在XML文件中給出定義的，然后利用Java 的“反射”編程，根據(jù)XML中給出的類(lèi)名生成相應(yīng)的對(duì)象。從實(shí)現(xiàn)來(lái)看，IoC是把以前在工廠方法里寫(xiě)死的對(duì)象生成代碼，改變?yōu)橛蒟ML文件來(lái)定義，也就是 把工廠和對(duì)象生成這兩者獨(dú)立分隔開(kāi)來(lái)，目的就是提高靈活性和可維護(hù)性。
??? IoC中最基本的Java技術(shù)就是“反射”編程。反射又是一個(gè)生澀的名詞，通俗的說(shuō)反射就是根據(jù)給出的類(lèi)名（字符串）來(lái)生成對(duì)象。這種編程方式可以讓對(duì)象 在生成時(shí)才決定要生成哪一種對(duì)象。反射的應(yīng)用是很廣泛的，象Hibernate、String中都是用“反射”做為最基本的技術(shù)手段。
??? 在過(guò)去，反射編程方式相對(duì)于正常的對(duì)象生成方式要慢10幾倍，這也許也是當(dāng)時(shí)為什么反射技術(shù)沒(méi)有普通應(yīng)用開(kāi)來(lái)的原因。但經(jīng)SUN改良優(yōu)化后，反射方式生成對(duì)象和通常對(duì)象生成方式，速度已經(jīng)相差不大了（但依然有一倍以上的差距）。
??? IoC最大的好處是什么？因?yàn)榘褜?duì)象生成放在了XML里定義，所以當(dāng)我們需要換一個(gè)實(shí)現(xiàn)子類(lèi)將會(huì)變成很簡(jiǎn)單（一般這樣的對(duì)象都是現(xiàn)實(shí)于某種接口的），只要修改XML就可以了，這樣我們甚至可以實(shí)現(xiàn)對(duì)象的熱插撥（有點(diǎn)象USB接口和SCIS硬盤(pán)了）。
??? IoC最大的缺點(diǎn)是什么？（1）生成一個(gè)對(duì)象的步驟變復(fù)雜了（其實(shí)上操作上還是挺簡(jiǎn)單的），對(duì)于不習(xí)慣這種方式的人，會(huì)覺(jué)得有些別扭和不直觀。（2）對(duì)象 生成因?yàn)槭鞘褂梅瓷渚幊?#xff0c;在效率上有些損耗。但相對(duì)于IoC提高的維護(hù)性和靈活性來(lái)說(shuō)，這點(diǎn)損耗是微不足道的，除非某對(duì)象的生成對(duì)效率要求特別高。（3） 缺少I(mǎi)DE重構(gòu)操作的支持，如果在Eclipse要對(duì)類(lèi)改名，那么你還需要去XML文件里手工去改了，這似乎是所有XML方式的缺憾所在。 IOC實(shí)現(xiàn)初探 ?? IOC關(guān)注服務(wù)(或應(yīng)用程序部件)是如何定義的以及他們應(yīng)該如何定位他們依賴(lài)的其它服務(wù)。通常，通過(guò)一個(gè)容器或定位框架來(lái)獲得定義和定位的分離，容器或定位框架負(fù)責(zé)：

• 保存可用服務(wù)的集合
• 提供一種方式將各種部件與它們依賴(lài)的服務(wù)綁定在一起
• 為應(yīng)用程序代碼提供一種方式來(lái)請(qǐng)求已配置的對(duì)象(例如，一個(gè)所有依賴(lài)都滿(mǎn)足的對(duì)象)， 這種方式可以確保該對(duì)象需要的所有相關(guān)的服務(wù)都可用。

現(xiàn)有的框架實(shí)際上使用以下三種基本技術(shù)的框架執(zhí)行服務(wù)和部件間的綁定:

• 類(lèi)型1 (基于接口): 可服務(wù)的對(duì)象需要實(shí)現(xiàn)一個(gè)專(zhuān)門(mén)的接口，該接口提供了一個(gè)對(duì)象，可以從用這個(gè)對(duì)象查找依賴(lài)(其它服務(wù))。早期的容器Excalibur使用這種模式。
• 類(lèi)型2 (基于setter): 通過(guò)JavaBean的屬性(setter方法)為可服務(wù)對(duì)象指定服務(wù)。HiveMind和Spring采用這種方式。
• 類(lèi)型3 (基于構(gòu)造函數(shù)): 通過(guò)構(gòu)造函數(shù)的參數(shù)為可服務(wù)對(duì)象指定服務(wù)。PicoContainer只使用這種方式。HiveMind和Spring也使用這種方式。

轉(zhuǎn)載于:https://www.cnblogs.com/EricGu/archive/2007/12/21/1009279.html

總結(jié)

以上是生活随笔為你收集整理的IOC的介绍的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。