IoC是什麼？Inversion of Control，即反轉控制，或許說為依賴注入更為合適。IoC就是IoC，不是什麼技術，與GoF一樣，是一種設計模式。
Interface Driven Design介面驅動，介面驅動有很多好處，可以提供不同靈活的子類實現，增加程式碼穩定和健壯性等等，但是介面一定是需要實現的，也就是如下語句遲早要執 行：AInterface a = new AInterfaceImp(); 這樣一來，耦合關係就產生了，如：

class A{  
    AInterface a;  

    A(){  
        a = new AInterfaceImp();  
    }  
}  
 

Class A與AInterfaceImp就是依賴關係，如果想使用AInterface的另外一個實現就需要更改程式碼了。當然我們可以建立一個Factory來根據條件生成想要的AInterface的具體實現，即：

class InterfaceImplFactory{  

    AInterface create(Object condition){  
        if(condition = condA){  
            return new AInterfaceImpA();  
        }elseif(condition = condB){  
            return
 
 new AInterfaceImpB();  
        }else{  
            return new AInterfaceImp();  
        }  
    }  
}  

 表 面上是在一定程度上緩解了以上問題，但實質上這種程式碼耦合並沒有改變。通過IoC模式可以徹底解決這種耦合，它把耦合從程式碼中移出去，放到統一的XML文 件中，通過一個容器在需要的時候把這個依賴關係形成，即把需要的介面實現注入到需要它的類中，這可能就是“依賴注入”說法的來源了。
IOC模式，系統中通過引入實現了IOC模式的IOC容器，即可由IOC容器來管理物件的生命週期、依賴關係等，從而使得應用程式的配置和依賴性規範與實 際的應用程式程式碼分開。其中一個特點就是通過文字的配件檔案進行應用程式元件間相互關係的配置，而不用重新修改並編譯具體的程式碼。
 

當前比較知名的IOC容器有：Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。
在上面的幾個IOC容器中，輕量級的有Pico Container、Avalon、Spring、HiveMind等，超重量級的有EJB，而半輕半重的有容器有JBoss，Jdon等。
可以把IoC模式看做是工廠模式的昇華，可以把IoC看作是一個大工廠，只不過這個大工廠裡要生成的物件都是在XML檔案中給出定義的，然後利用Java 的“反射”程式設計，根據XML中給出的類名生成相應的物件。從實現來看，IoC是把以前在工廠方法裡寫死的物件生成程式碼，改變為由XML檔案來定義，也就是 把工廠和物件生成這兩者獨立分隔開來，目的就是提高靈活性和可維護性。
IoC中最基本的Java技術就是“反射”程式設計。反射又是一個生澀的名詞，通俗的說反射就是根據給出的類名（字串）來生成物件。這種程式設計方式可以讓物件 在生成時才決定要生成哪一種物件。反射的應用是很廣泛的，象Hibernate、String中都是用“反射”做為最基本的技術手段。
在過去，反射程式設計方式相對於正常的物件生成方式要慢10幾倍，這也許也是當時為什麼反射技術沒有普通應用開來的原因。但經SUN改良優化後，反射方式生成物件和通常物件生成方式，速度已經相差不大了（但依然有一倍以上的差距）。

IoC最大的好處是什麼？

 因為把物件生成放在了XML裡定義，所以當我們需要換一個實現子類將會變成很簡單（一般這樣的物件都是現實於某種介面的），只要修改XML就可以了，這樣我們甚至可以實現物件的熱插撥（有點象USB介面和SCIS硬碟了）。

IoC最大的缺點是什麼？
（1）生成一個物件的步驟變複雜了（其實上操作上還是挺簡單的），對於不習慣這種方式的人，會覺得有些彆扭和不直觀。
（2）物件 生成因為是使用反射程式設計，在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某物件的生成對效率要求特別高。
（3） 缺少IDE重構操作的支援，如果在Eclipse要對類改名，那麼你還需要去XML檔案裡手工去改了，這似乎是所有XML方式的缺憾所在。