ioc（inversion of control）即控制反轉技術，其基本原理是基於所謂hollywood模式思想：don't call me , i'll call you!思想。也就是說，所有的元件都是被動的，所有元件初始化和呼叫都有容器負責。元件處在容器當中，有容器負責管理。
舉乙個例子,公司有一台聯想的印表機負責公司內部財務資料列印服務。於是建立乙個pringservice類。
pactage test;
public class printservice
public void printinfo(string info)
}這樣如果我們需要列印資料，則這樣引用印表機服務：
public class financereport()
public void printreport (string info)
}但是，這樣的話如果公司業務量增加，於是有購買了一台 hp 印表機。那麼為了支援多台印表機的情況，就需要對印表機服務類作改動。
package test;
public class printservice
public void printinfo(string info)
}但是這樣就導致了原來的financereport不可用，需要改動
在financereport**中需要在new printservice ();作出改動已指定印表機型別；但是這裡只是乙個financereport（財務列印），如果公司有很多態別的資料需要列印，那麼就會有很多的和financereport一樣的類，那麼就需要逐個改動，很是麻煩，而出現這個問題的原因就是financereport類對printservice類的耦合太緊，依賴太深。
下面給出解決方案：
package test;
public class financereport
public void printreport(string reportinfo)
//需要時動態的設定它
public void setprintservice (printservice printservice)
}上述**很大的乙個改動就是沒有直接的: new printservice()；而是需要時在外部動態的設定它，這樣就消除了fincereport類和printservice類的強耦合；
下面再來分析financereport類，有上面的分析知道我們為了實現解耦，而動態的設定printservice，但是我們並不知道是如何得到service例項的，也就是說service的dependency（依賴）在那裡我們無從知曉，但是我們可以知道service完全可以滿足我們的需求，因為service是printservice型別的。那麼誰應該具體負責提供service的dependency呢？這就是ioc容器的責任了。ioc容器的責任就是負責向應用程式中提供dependency的。經過上面的改變，獲取服務的依賴性的責任就由使用者**轉移到容器中了，這就是責任的遷移。結合上面的「don't call me,i'll call you」的原則，就可以理解。這樣做的優點非常多最核心的一條就是大大降低了**的耦合度。
IoC容器筆記2
例項化ioc容器 例項化ioc容器很簡單.下面是一段示例 如果有多個配置檔案,則可以使用陣列的形式 關於元素 我們已經知道,可以通過建構函式從配置的xml中載入bean的定義.如果這個建構函式需要多個資源位置,如上所示.或者,可以使用一次或者多次元素載入bean的定義,示例如下 使用ioc容器 建立...
Spring學習 IOC容器 xml
1.xml檔案配置 2.註解 commons logging 1.2 bin spring framework 4.3.0.release dist匯入到專案 建立乙個類，用來完成對spring配置檔案的載入和銷毀 所有的單元測試類都必須繼承自上類，並且都必須加註解 runwith blockjun...
spring學習之IoC容器
jinnianshilongnian 寫道 理解ioc容器問題關鍵 控制的哪些方面被反轉了？1 誰控制誰？為什麼叫反轉？ioc容器控制，而以前是應用程式控制，所以叫反轉 2 控制什麼？控制應用程式所需要的資源 物件 檔案 3 為什麼控制？解耦元件之間的關係 4 控制的哪些方面被反轉了？程式的控制權發...