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