摘要：上面這部分代碼不變，還是通過在構(gòu)造器中傳入依賴的方式初始化依賴調(diào)用這里，調(diào)用方無需了解內(nèi)部對的依賴。而配置一般用于上自動掃描并注入的代碼如下這里只給出直接在依賴對象上添加注解的形式，還可以通過構(gòu)造器和注入依賴，這里就不多說了。

相信所有面試java開發(fā)的童鞋一定都被問到過是否使用過Spring，是否了解其IOC容器，為什么不直接使用工廠模式，以及究竟IOC和DI區(qū)別在于哪里這種問題。今天就結(jié)合JAVA語言，解釋一下究竟是如何衍生出DI模式，以及其在Spring中的實現(xiàn)。

初學(xué)Java，我們一定會學(xué)到面向?qū)ο蟮木幊趟枷耄约笆褂胣ew關(guān)鍵字新建一個對象。假設(shè)現(xiàn)在有一個郵件發(fā)送系統(tǒng)，該系統(tǒng)包含拼寫檢查功能。那么本著面向?qū)ο蟮乃枷胍约瓣P(guān)注點分離的思想，我們會將其分解為兩個類：Emailer和SpellChecker。其中，Emailer依賴著SpellChecker提供的服務(wù)，這兩個類的實現(xiàn)如下：

public class SpellChecker{
    ...
    public void check(){
       ...
    }
}

public class Emailer{
    private SpellChecker spellChecker;
    public Emailer(){
        spellChecker = new SpellChecker();
    }
}

可以看到我們在構(gòu)造器中使用new新建了一個SpellChecker的對象。

現(xiàn)在我們來分析一下這個實現(xiàn)的不足之處：

可測試性：假設(shè)現(xiàn)在我希望測試Emailer的功能是否完善，但是此時SpellChecker并沒有完成開發(fā)與測試，那么我們將無法對Emailer進(jìn)行測試。就算SpellChecker已經(jīng)開發(fā)完成，但是我們也無法排除當(dāng)前的錯誤是否和SpellChecker的實現(xiàn)無關(guān)。

可維護(hù)性：假設(shè)現(xiàn)在支持多語種，那么我需要分別實現(xiàn)一個EnglishEmailer和FrenchEmailer類。他們的構(gòu)造函數(shù)中分別初始化EnglishSpellChecker和FrenchSpellChecker。以后每增加一個語種都需要新建一個新的Emailer類。而這些類的代碼本質(zhì)上都是重復(fù)的。更不要提假設(shè)里面

因此我們就需要一種新的初始化依賴的方式。

既然在調(diào)用依賴的類中初始化依賴這么麻煩，不如將構(gòu)建完成的依賴傳入調(diào)用的類。

public class SpellChecker{
    ...
    public void check(){
       ...
    }
}

public class Emailer{
    private SpellChecker spellChecker;
    public Emailer(SpellChecker spellChecker){
        this.spellChecker = spellChecker;
    }
}
//使用
Emailer email = new Emailer(new EnglishSpellChecker())

從測試性的角度來說，這個代碼明顯更加易于測試了，我們可以提供SpellChecker的一個Mock實現(xiàn)，如Emailer e = new Emailer(new MockSpellChecker())來對Emailer進(jìn)行測試。那么這種實現(xiàn)的缺點在哪里呢？

首先，調(diào)用Emailer的代碼需要知道如何去初始化SpellChecker，而這明顯暴露了Emailer的內(nèi)部實現(xiàn)，違背了信息隱藏的思想。其次，一旦依賴發(fā)生變化，比如Emailer還需要依賴一個定時裝置Scheduler來實現(xiàn)定時發(fā)送郵件，那么所有的調(diào)用Emailer的代碼都需要發(fā)生改變。顯然，這種寫法的可維護(hù)性依然不高。

那么，我們是否可以將所有對象構(gòu)建的代碼提取出來，像工廠標(biāo)準(zhǔn)件一樣生產(chǎn)出來。所有對對象的調(diào)用都通過工廠提供。

public class SpellChecker{
    ...
    public void check(){
       ...
    }
}

public class Emailer{
    private SpellChecker spellChecker;
    public Emailer(SpellChecker spellChecker){
        this.spellChecker = spellChecker;
    }
}
//上面這部分代碼不變，還是通過在構(gòu)造器中傳入依賴的方式初始化依賴

public class EmailerFactory {
    public Emailer newFrenchEmailer(){
        return new Emailer(new FrenchSpellChecker());
    }
}

//調(diào)用
Emailer email = new EmailerFactory().newFrenchEmailer();

這里，調(diào)用方無需了解內(nèi)部對SpellChecker的依賴。無論之后Emailer的依賴發(fā)生什么樣的變化，客戶端代碼都不會受到影響。那么這種設(shè)計有沒有缺陷呢？

當(dāng)然是有的。Emailer的測試和之前一樣，我們可以通過傳入Mock的對象來對其進(jìn)行測試。那么調(diào)用Emailer的服務(wù)怎么辦呀？在調(diào)用方看來我們只是依賴著Factory對象，因此我們需要通過定義Factory返回一個Mock對象才行，同時這個對象還不能影響真正的Factory的實現(xiàn)。

除此以外，每當(dāng)我們對一個新的語種添加支持時，我們都必須添加一段新的代碼，如下：

public class EmailerFactory {
    public Emailer newJapaneseEmailer() {
        Emailer service = new Emailer();
        service.setSpellChecker(new JapaneseSpellChecker());
        return service;
    }
    public Emailer newFrenchEmailer() {
        Emailer service = new Emailer();
        service.setSpellChecker(new FrenchSpellChecker());
        return service;
    } 
}

而這兩段初始化代碼基本上是完全相同的！而假設(shè)以后我們需要實現(xiàn)一個全球通用版本。。。
光是無聊的工廠模式代碼就要花費我們大量的時間！

有沒有這樣一個東西，客戶端代碼報出它的編號key，它就會返回那個對象的實例。當(dāng)然這個實例是根據(jù)配置生成的。比如Emailer English這樣的key，就會返回英語的Emailer。這種思路衍生出了服務(wù)定位模式。這個模式相當(dāng)于站在了所有工廠模式的最前端。它就像是一個老式的電話中轉(zhuǎn)服務(wù)，調(diào)用服務(wù)的人輸入服務(wù)的唯一編號，即電話號碼，而服務(wù)定位器找到該服務(wù)并返回該服務(wù)的實例。調(diào)用如下：

Emailer emailer = (Emailer) new ServiceLocator().get("Emailer");

JNDI（Java Naming and Directory Interface）就是該思想下的一個實現(xiàn)。服務(wù)的提供方在JNDI上注冊服務(wù)，之后調(diào)用方在JNDI上檢索服務(wù)，實現(xiàn)二者之間的解耦。

這個模式的問題和工廠模式類似，難以測試以及需要管理共享狀態(tài)。其次，通過使用String類型的Key來獲取服務(wù)無法在編譯時對服務(wù)調(diào)用是否正確以及服務(wù)類型是否正確進(jìn)行檢查。

這里將不會給出JNDI的具體實現(xiàn)，對JNDI的概念有困惑的可以查看這篇文章

看來，任何和構(gòu)造對象相關(guān)的代碼夾雜在業(yè)務(wù)代碼中都會帶來麻煩，那么我們可以將這部分代碼全權(quán)委托給構(gòu)造框架，業(yè)務(wù)代碼通過依賴注入從而關(guān)注于業(yè)務(wù)本身，而框架可以通過配置甚至是自動的生成對象注入到客戶端。從而實現(xiàn)二者的完全解耦。

至此，對象關(guān)聯(lián)圖的構(gòu)造，聯(lián)系和組裝將和業(yè)務(wù)代碼完全無關(guān)，這種情況也被成為控制反轉(zhuǎn)（IOC）

不同的框架對于依賴注入的實現(xiàn)是不同的，但是本質(zhì)上來說，他們都確保了客戶端無需在業(yè)務(wù)代碼中了解注入的依賴是如何初始化的。

那么IOC和DI之間的區(qū)別究竟是什么呢？
IOC這個概念所表示的領(lǐng)域其實超出了依賴注入的范圍，它更多強調(diào)的是控制反轉(zhuǎn)，也就是說，這個對象是別人替你創(chuàng)建好的。因此DI是IOC的一種實現(xiàn)機制。而控制反轉(zhuǎn)可以運用于更多的場景，如：

J2EE應(yīng)用服務(wù)器中的一個模塊，比如Servlet

框架自動調(diào)用的測試方法

點擊鼠標(biāo)后調(diào)用的事件處理器

IOC不僅負(fù)責(zé)創(chuàng)建對象，還需要管理對象的生命周期。不同的生命周期需要觸發(fā)不同的調(diào)用，這些調(diào)用被稱為回調(diào)函數(shù)。除此以外，IOC容器管理的對象需要被打上標(biāo)記，比如使用@Autowire,@Component注解的類和對象，以及繼承了Servlet接口的Servlet才會被Servlet容器管理。

因此我們常見的Spring更像是將IOC和DI思想結(jié)合在一起生成的產(chǎn)物。

更多關(guān)于IOC VS DI可以參考這篇文章

Spring是一個輕量級的依賴注入框架，它已經(jīng)成了所有JAVA開發(fā)者無法躲開的開發(fā)大禮包。Spring提供了三種依賴注入的方式：XML，注解和Java Config

XML方式曾經(jīng)非常流行，但是這種方式也逐漸暴露出問題，主要的問題在于無法對注入的依賴進(jìn)行類型檢查，從而導(dǎo)致代碼無法在編譯期間識別出問題，只能在運行期間拋出異?！，F(xiàn)在主要推薦自動掃描并注入以及通過JavaConfig代碼來配置。而XML配置一般用于Legacy System上

自動掃描并注入的代碼如下：

public class Emailer{
    @Autowired
    private SpellChecker spellChecker;

    public class Emailer(SpellChecker spellChecker){
    }    
}

@Component
public class SpellChecker{
    ...
}

@ComponentScan
public class EmailerConfig{
}

這里只給出直接在依賴對象上添加注解的形式，還可以通過構(gòu)造器和setter注入依賴，這里就不多說了。

Java Config則是將配置代碼多帶帶提取出來：

@Configuration
public class EmailerConfig{
    @Bean
    public Emailer EnglishEmailer(){
        return new Emailer(new EnglishSpellChecker());
    }
}

當(dāng)然，這里也可以通過依賴注入的方式來確保傳入的對象是單例的（默認(rèn)情況下Spring生成的對象為單例）

@Configuration
public class EmailerConfig{
    @Bean
    public Emailer EnglishEmailer(SpellChecker spellChecker){
        return new Emailer(spellChecker);
    }
}

想要了解更多開發(fā)技術(shù)，面試教程以及互聯(lián)網(wǎng)公司內(nèi)推，歡迎關(guān)注我的微信公眾號！將會不定期的發(fā)放福利哦~