IoC 亦稱爲 「依賴倒置原理」("Dependency Inversion Principle")。差很少全部框架都使用了「倒置注入(Fowler 2004)技巧,這可說是IoC原理的一項應用。SmallTalk,C++, Java 或各類.NET 語言等面向對象程序語言的程序員已使用了這些原理。html
控制反轉是Spring框架的核心。程序員
應用控制反轉,對象在被建立的時候,由一個調控系統內全部對象的外界實體,將其所依賴的對象的引用,傳遞給它。也能夠說,依賴被注入到對象中。因此,控制反轉是,關於一個對象如何獲取他所依賴的對象的引用,這個責任的反轉。web
IoC就是IoC,不是什麼技術,與GoF同樣,是一種設計模式。編程
Interface Driven Design接口驅動,接口驅動有不少好處,能夠提供不一樣靈活的子類實現,增長代碼穩定和健壯性等等,可是接口必定是須要實現的,也就是以下語句早晚要執行:AInterface a = new AInterfaceImp(); 這樣一來,耦合關係就產生了,如:設計模式
Class A { AInterface a; A() { } aMethod() { a = new AInterfaceImp(); } }
ClassA與AInterfaceImp就是依賴關係,若是想使用AInterface的另一個實現就須要更改代碼了。固然咱們能夠創建一個Factory來根據條件生成想要的AInterface的具體實現,即:框架
InterfaceImplFactory { AInterface create(Object condition) { if(condition = condA) { return new AInterfaceImpA(); } elseif(condition = condB) { return new AInterfaceImpB(); } else { return new AInterfaceImp(); } } }
表面上是在必定程度上緩解了以上問題,但實質上這種代碼耦合並無改變。經過IoC模式能夠完全解決這種耦合,它把耦合從代碼中移出去,放到統一的XML 文件中,經過一個容器在須要的時候把這個依賴關係造成,即把須要的接口實現注入到須要它的類中,這可能就是「依賴注入」說法的來源了。ide
IOC模式,系統中經過引入實現了IOC模式的IOC容器,便可由IOC容器來管理對象的生命週期、依賴關係等,從而使得應用程序的配置和依賴性規範與實際的應用程序代碼分開。其中一個特色就是經過文本的配置文件進行應用程序組件間相互關係的配置,而不用從新修改並編譯具體的代碼。優化
當前比較知名的IOC容器有:Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。url
在上面的幾個IOC容器中,輕量級的有Pico Container、Avalon、Spring、HiveMind等,超重量級的有EJB,而半輕半重的有容器有JBoss,Jdon等。spa
能夠把IoC模式看作是工廠模式的昇華,能夠把IoC看做是一個大工廠,只不過這個大工廠裏要生成的對象都是在XML文件中給出定義的,而後利用Java 的「反射」編程,根據XML中給出的類名生成相應的對象。從實現來看,IoC是把之前在工廠方法裏寫死的對象生成代碼,改變爲由XML文件來定義,也就是把工廠和對象生成這二者獨立分隔開來,目的就是提升靈活性和可維護性。
IoC中最基本的Java技術就是「反射」編程。反射又是一個生澀的名詞,通俗的說反射就是根據給出的類名(字符串)來生成對象。這種編程方式可讓對象在生成時才決定要生成哪種對象。反射的應用是很普遍的,象Hibernate、Spring中都是用「反射」作爲最基本的技術手段。
在過去,反射編程方式相對於正常的對象生成方式要慢10幾倍,這也許也是當時爲何反射技術沒有普通應用開來的緣由。但經SUN改良優化後,反射方式生成對象和一般對象生成方式,速度已經相差不大了(但依然有一倍以上的差距)。
IoC最大的好處是什麼?由於把對象生成放在了XML裏定義,因此當咱們須要換一個實現子類將會變成很簡單(通常這樣的對象都是實現於某種接口的),只要修改XML就能夠了,這樣咱們甚至能夠實現對象的熱插撥(有點象USB接口和SCIS硬盤了)。
IoC最大的缺點是什麼?(1)生成一個對象的步驟變複雜了(其實上操做上仍是挺簡單的),對於不習慣這種方式的人,會以爲有些彆扭和不直觀。(2)對象生成由於是使用反射編程,在效率上有些損耗。但相對於IoC提升的維護性和靈活性來講,這點損耗是微不足道的,除非某對象的生成對效率要求特別高。(3)缺乏IDE重構操做的支持,若是在Eclipse要對類更名,那麼你還須要去XML文件裏手工去改了,這彷佛是全部XML方式的缺憾所在