好久寫有關java技術的文章了，這幾天在圖書館看到《Spring in Action》就借過來隨手翻翻，覺得第一章的IoC的概念講的很好，現在整理如下。
（1）從類的耦合說起
在實際的系統中，要多個類共同協作來完成某一項任務，一般稱為復合。在系統的設計過程中，耦合是不可避免的，是必須的，但是它會帶來以下問題：
－－難以測試：看下面的兩個類：
KnightOfTheRoundTable
????????????????? |
????????????????? |??new
?????????????????V
???????? HolyGrailQuest
在KnightOfTheRoundTable類中使用了HolyGrailQuest類，并且可能使用不同的Quest類。這兩個類的功能是騎士去執行不同的任務，HolyGrail只是代表了一種任務。這種通過國new的方式，使得knight和quest兩個類緊密的耦合在一起。設計完成后做單元測試，看下面的代碼：
KnightOfTheRoundTable knight = new KnightOfTheRoundTable("Bedivere");
HolyGrail grail = knight.embarkOnQuery();
assertNotNull(grail);
assertTrue(grail.isHoly());
在測試KnightOfTheRoundTable類的時候，間接的測試了HolyGrailQuest類，但是對于HolyGrailQuest類的情況并沒有很顯式的測試，所以使用了最后的兩行代碼來測試，顯得很笨拙。不知道是否測試了所有可能的情況。
－－難以維護
如果以后修改了代碼，或者增加了/改變了knight的任務，代碼必須改動，測試代碼也要改動，并且改動一個地方，可能會影響到其他很多地方，為日后的維護工作帶來了麻煩
－－緊耦合
提示：這種模式引起的問題，主要是因為緊耦合所致，所以要解決這種問題的首要方案就是解耦合，但如何來解耦合呢？請繼續看：
（2）解耦合——通過接口interface來實現
因為騎士可能執行不同的任務，也有不同種類的騎士，所以我們可以將任務和騎士抽象為接口，將具體的實現隱藏在接口之下，這樣就不必在knight類中通過顯示的 HolyGrailQuest quest = new HolyGrailQuest ()這樣的語句來創建Quest對象，而可以通過接口Quest quest ＝ new HolyGrailQuest()來實現。這樣就形成了如下的類圖：
這樣，雖然使用了接口，使得層次分明，通過接口Quest來實現探險，但是還是只能從事一種探險任務，而如何才能讓騎士從事任何一種任務呢？請繼續看！
（3）給予與獲得
騎士執行探險任務有兩種方式：
第一、讓騎士主動獲得探險任務，前面的實現方式屬于這類，通過new來實現；
第二，讓騎士被動的獲得任務，即給予騎士某項探險任務，這樣就解決了上面的問題（讓騎士可以從事任何一種任務，只要給他們分配即可）。
實際實現的方式很簡單，看如下代碼：
public void setQuest(Quest quest){
?? this.quest = quest;
}
簡單的代碼實現了方式的改變，這樣給KnightOfTheRoundTable類傳入任何的Quest任務，都可以接受了。
到這里可以很明顯的看出來，我們將以前的new方式，翻轉過來，即不是讓主動獲得依賴類，而是被動的獲得依賴類，這就是IoC的核心，實際Fowler說得依賴注入也很貼切，即向類中“注入”它依賴的其他類。
好了，到這里，應該知道了IoC的基本概念了吧，也知道了IoC的基本功能了吧。
要想更深入的了解，請關注我的文章。