????????控制反轉(zhuǎn)（Inversion of Control麻削，英文縮寫為IoC）把創(chuàng)建對(duì)象的權(quán)利交給框架,是框架的重要特征，并非面向?qū)ο缶幊?/a>的專用術(shù)語饭聚。它包括依賴注入（Dependency Injection称杨，簡(jiǎn)稱DI）和依賴查找（Dependency Lookup）绰沥。

IoC可以認(rèn)為是一種全新的設(shè)計(jì)模式，但是理論和時(shí)間成熟相對(duì)較晚蔚万，并沒有包含在GoF中岭妖。

? ? ????Interface Driven Design接口驅(qū)動(dòng)，接口驅(qū)動(dòng)有很多好處，可以提供不同靈活的子類實(shí)現(xiàn)昵慌，增加代碼穩(wěn)定和健壯性等等假夺，但是接口一定是需要實(shí)現(xiàn)的，也就是如下語句遲早要執(zhí)行：AInterface a = new AInterfaceImp(); 這樣一來废离，耦合關(guān)系就產(chǎn)生了

????????IoC模式侄泽，系統(tǒng)中通過引入實(shí)現(xiàn)了IoC模式的IoC容器，即可由IoC容器來管理對(duì)象的生命周期蜻韭、依賴關(guān)系等悼尾，從而使得應(yīng)用程序的配置和依賴性規(guī)范與實(shí)際的應(yīng)用程序代碼分開。其中一個(gè)特點(diǎn)就是通過文本的配置文件進(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è)大工廠，只不過這個(gè)大工廠里要生成的對(duì)象都是在XML文件中給出定義的踩官，然后利用Java 的“反射”編程却桶，根據(jù)XML中給出的類名生成相應(yīng)的對(duì)象。從實(shí)現(xiàn)來看卖鲤，IoC是把以前在工廠方法里寫死的對(duì)象生成代碼肾扰，改變?yōu)橛蒟ML文件來定義，也就是把工廠和對(duì)象生成這兩者獨(dú)立分隔開來蛋逾，目的就是提高靈活性和可維護(hù)性集晚。

????????IoC中最基本的Java技術(shù)就是“反射”編程。反射又是一個(gè)生澀的名詞区匣，通俗的說反射就是根據(jù)給出的類名（字符串）來生成對(duì)象偷拔。這種編程方式可以讓對(duì)象在生成時(shí)才決定要生成哪一種對(duì)象蒋院。反射的應(yīng)用是很廣泛的，像Hibernate莲绰、Spring中都是用“反射”做為最基本的技術(shù)手段欺旧。

????????在過去，反射編程方式相對(duì)于正常的對(duì)象生成方式要慢10幾倍蛤签，這也許也是當(dāng)時(shí)為什么反射技術(shù)沒有普遍應(yīng)用開來的原因辞友。但經(jīng)SUN改良優(yōu)化后，反射方式生成對(duì)象和通常對(duì)象生成方式震肮，速度已經(jīng)相差不大了（但依然有一倍以上的差距）称龙。

優(yōu)缺點(diǎn)

????????IoC最大的好處是什么？因?yàn)榘褜?duì)象生成放在了XML里定義戳晌，所以當(dāng)我們需要換一個(gè)實(shí)現(xiàn)子類將會(huì)變成很簡(jiǎn)單（一般這樣的對(duì)象都是實(shí)現(xiàn)于某種接口的）鲫尊，只要修改XML就可以了，這樣我們甚至可以實(shí)現(xiàn)對(duì)象的熱插拔（有點(diǎn)像USB接口和SCSI硬盤了）沦偎。

????????IoC最大的缺點(diǎn)是什么疫向？（1）生成一個(gè)對(duì)象的步驟變復(fù)雜了（事實(shí)上操作上還是挺簡(jiǎn)單的），對(duì)于不習(xí)慣這種方式的人豪嚎，會(huì)覺得有些別扭和不直觀搔驼。（2）對(duì)象生成因?yàn)槭鞘褂梅瓷渚幊蹋谛噬嫌行p耗侈询。但相對(duì)于IoC提高的維護(hù)性和靈活性來說匙奴，這點(diǎn)損耗是微不足道的，除非某對(duì)象的生成對(duì)效率要求特別高妄荔。（3）缺少IDE重構(gòu)操作的支持，如果在Eclipse要對(duì)類改名谍肤，那么你還需要去XML文件里手工去改了啦租，這似乎是所有XML方式的缺陷所在。

實(shí)現(xiàn)初探

????????IOC關(guān)注服務(wù)(或應(yīng)用程序部件)是如何定義的以及他們應(yīng)該如何定位他們依賴的其它服務(wù)荒揣。通常篷角，通過一個(gè)容器或定位框架來獲得定義和定位的分離，容器或定位框架負(fù)責(zé)：

保存可用服務(wù)的集合

提供一種方式將各種部件與它們依賴的服務(wù)綁定在一起

????????為應(yīng)用程序代碼提供一種方式來請(qǐng)求已配置的對(duì)象(例如系任，一個(gè)所有依賴都滿足的對(duì)象)恳蹲， 這種方式可以確保該對(duì)象需要的所有相關(guān)的服務(wù)都可用。

類型

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

????????類型1 (基于接口): 可服務(wù)的對(duì)象需要實(shí)現(xiàn)一個(gè)專門的接口俩滥，該接口提供了一個(gè)對(duì)象嘉蕾，可以重用這個(gè)對(duì)象查找依賴(其它服務(wù))。早期的容器Excalibur使用這種模式霜旧。

????????類型2 (基于setter): 通過JavaBean的屬性(setter方法)為可服務(wù)對(duì)象指定服務(wù)错忱。HiveMind和Spring采用這種方式。

????????類型3 (基于構(gòu)造函數(shù)):通過構(gòu)造函數(shù)的參數(shù)為可服務(wù)對(duì)象指定服務(wù)。PicoContainer只使用這種方式以清。HiveMind和Spring也使用這種方式

實(shí)現(xiàn)策略

IoC是一個(gè)很大的概念,可以用不同的方式實(shí)現(xiàn)儿普。其主要形式有兩種：

◇依賴查找：容器提供回調(diào)接口和上下文條件給組件。EJB和Apache Avalon 都使用這種方式掷倔。這樣一來眉孩，組件就必須使用容器提供的API來查找資源和協(xié)作對(duì)象，僅有的控制反轉(zhuǎn)只體現(xiàn)在那些回調(diào)方法上（也就是上面所說的 類型1）：容器將調(diào)用這些回調(diào)方法勒葱，從而讓應(yīng)用代碼獲得相關(guān)資源浪汪。

◇依賴注入：組件不做定位查詢，只提供普通的Java方法讓容器去決定依賴關(guān)系错森。容器全權(quán)負(fù)責(zé)的組件的裝配吟宦，它會(huì)把符合依賴關(guān)系的對(duì)象通過JavaBean屬性或者構(gòu)造函數(shù)傳遞給需要的對(duì)象。通過JavaBean屬性注射依賴關(guān)系的做法稱為設(shè)值方法注入(Setter Injection)涩维；將依賴關(guān)系作為構(gòu)造函數(shù)參數(shù)傳入的做法稱為構(gòu)造器注入（Constructor Injection）

實(shí)現(xiàn)方式

實(shí)現(xiàn)數(shù)據(jù)訪問層

????????數(shù)據(jù)訪問層有兩個(gè)目標(biāo)殃姓。第一是將數(shù)據(jù)庫引擎從應(yīng)用中抽象出來，這樣就可以隨時(shí)改變數(shù)據(jù)庫—比方說瓦阐，從微軟SQL變成Oracle蜗侈。不過在實(shí)踐上很少會(huì)這么做，也沒有足夠的理由未來使用實(shí)現(xiàn)數(shù)據(jù)訪問層而進(jìn)行重構(gòu)現(xiàn)有應(yīng)用的努力睡蟋。

????????第二個(gè)目標(biāo)是將數(shù)據(jù)模型從數(shù)據(jù)庫實(shí)現(xiàn)中抽象出來踏幻。這使得數(shù)據(jù)庫或代碼開源根據(jù)需要改變，同時(shí)只會(huì)影響主應(yīng)用的一小部分——數(shù)據(jù)訪問層戳杀。這一目標(biāo)是值得的该面，為了在現(xiàn)有系統(tǒng)中實(shí)現(xiàn)它進(jìn)行必要的重構(gòu)。

模塊與接口重構(gòu)

????????依賴注入背后的一個(gè)核心思想是單一功能原則（single responsibility principle）信卡。該原則指出隔缀，每一個(gè)對(duì)象應(yīng)該有一個(gè)特定的目的，而應(yīng)用需要利用這一目的的不同部分應(yīng)當(dāng)使用合適的對(duì)象傍菇。這意味著這些對(duì)象在系統(tǒng)的任何地方都可以重用猾瘸。但在現(xiàn)有系統(tǒng)里面很多時(shí)候都不是這樣的。?

隨時(shí)增加單元測(cè)試

????????把功能封裝到整個(gè)對(duì)象里面會(huì)導(dǎo)致自動(dòng)測(cè)試?yán)щy或者不可能丢习。將模塊和接口與特定對(duì)象隔離牵触，以這種方式重構(gòu)可以執(zhí)行更先進(jìn)的單元測(cè)試。按照后面再增加測(cè)試的想法繼續(xù)重構(gòu)模塊是誘惑力的咐低，但這是錯(cuò)誤的揽思。

使用服務(wù)定位器而不是構(gòu)造注入

????????實(shí)現(xiàn)控制反轉(zhuǎn)不止一種方法。最常見的辦法是使用構(gòu)造注入渊鞋，這需要在對(duì)象首次被創(chuàng)建是提供所有的軟件依賴绰更。然而瞧挤，構(gòu)造注入要假設(shè)整個(gè)系統(tǒng)都使用這一模式，這意味著整個(gè)系統(tǒng)必須同時(shí)進(jìn)行重構(gòu)儡湾。這很困難特恬、有風(fēng)險(xiǎn)，且耗時(shí)徐钠。