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

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

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

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

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

可以看到我們?cè)跇?gòu)造器中使用new新建了一個(gè)SpellChecker的對(duì)象。

現(xiàn)在我們來(lái)分析一下這個(gè)實(shí)現(xiàn)的不足之處：

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

可維護(hù)性：假設(shè)現(xiàn)在支持多語(yǔ)種，那么我需要分別實(shí)現(xiàn)一個(gè)EnglishEmailer和FrenchEmailer類。他們的構(gòu)造函數(shù)中分別初始化EnglishSpellChecker和FrenchSpellChecker。以后每增加一個(gè)語(yǔ)種都需要新建一個(gè)新的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())

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

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

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

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

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

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

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

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

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

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

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è)以后我們需要實(shí)現(xiàn)一個(gè)全球通用版本。。。
光是無(wú)聊的工廠模式代碼就要花費(fèi)我們大量的時(shí)間！

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

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

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

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

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

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

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

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

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

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

框架自動(dòng)調(diào)用的測(cè)試方法

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

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

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

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

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

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

自動(dòng)掃描并注入的代碼如下：

public class Emailer{
    @Autowired
    private SpellChecker spellChecker;

    public class Emailer(SpellChecker spellChecker){
    }    
}

@Component
public class SpellChecker{
    ...
}

@ComponentScan
public class EmailerConfig{
}

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

Java Config則是將配置代碼多帶帶提取出來(lái)：

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

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

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

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