摘要：滿足此要求的簡(jiǎn)單模式是在創(chuàng)建新實(shí)例時(shí)將資源傳遞給構(gòu)造函數(shù)。依賴注入同樣適用于構(gòu)造函數(shù)靜態(tài)工廠第項(xiàng)和構(gòu)建器第項(xiàng)。將資源工廠傳遞給構(gòu)造函數(shù)就會(huì)變成一個(gè)有用的模式。這種做法稱為依賴注入，將極大地增強(qiáng)類的靈活性，可重用性和可測(cè)試性。

??許多類依賴于一個(gè)或多個(gè)底層資源。 例如，拼寫檢查器依賴于字典。常見(jiàn)的做法是將這些類實(shí)現(xiàn)為靜態(tài)實(shí)用程序類(第4項(xiàng))：

// Inappropriate use of static utility - inflexible & untestable!
public class SpellChecker {
    private static final Lexicon dictionary = ...;
    private SpellChecker() {} // Noninstantiable
    public static boolean isValid(String word) { ... }
    public static List suggestions(String typo) { ... }
}

??同樣的，將它們作為單例實(shí)現(xiàn)的情況并不少見(jiàn)(第3項(xiàng))：

// Inappropriate use of singleton - inflexible & untestable!
public class SpellChecker {
    private final Lexicon dictionary = ...;
    private SpellChecker(...) {}
    public static INSTANCE = new SpellChecker(...);
    public boolean isValid(String word) { ... }
    public List suggestions(String typo) { ... }
}

??這些方法都不令人滿意，因?yàn)樗鼈兗僭O(shè)只有一本值得使用的字典。 在實(shí)踐中，每種語(yǔ)言都有自己的字典，特殊字典用于特殊詞匯。 而且，可能需要使用特殊字典進(jìn)行測(cè)試。 假設(shè)單本字典就足以滿足所有情況，這是一廂情愿的想法。

??你可以嘗試讓SpellChecker支持多個(gè)詞典，方法是使字典字段為非final域，并添加一個(gè)方法來(lái)更改現(xiàn)有拼寫檢查器中的字典，但這在并發(fā)時(shí)設(shè)置會(huì)很笨拙，容易出錯(cuò)并且不可行。 靜態(tài)實(shí)用程序類和單例不適用于底層資源作為參數(shù)的類(Static utility classes and singletons are inappropriate for classes whose behavior is parameterized by an underlying resource.)。

??所需要的是能夠支持類的多個(gè)實(shí)例(在我們的示例中為SpellChecker)，每個(gè)實(shí)例都使用客戶端所需的資源(在我們的示例中為字典)。 滿足此要求的簡(jiǎn)單模式是在創(chuàng)建新實(shí)例時(shí)將資源傳遞給構(gòu)造函數(shù)。 這是依賴注入的一種形式：字典是拼寫檢查器的依賴項(xiàng)，并在創(chuàng)建時(shí)注入拼寫檢查器。

// Dependency injection provides flexibility and testability
public class SpellChecker {
    private final Lexicon dictionary;
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
    public boolean isValid(String word) { ... }
    public List suggestions(String typo) { ... }
}

??這種依賴注入很簡(jiǎn)單，以至于程序猿用了很多年卻不知道它有一個(gè)名稱。雖然我們的拼寫檢查器只有一個(gè)資源(字典)，但是依賴注入可以使用任意數(shù)量的資源和任意的依賴關(guān)系，它保留了不變性(第17項(xiàng))，因此多個(gè)客戶端可以共享依賴對(duì)象(假設(shè)客戶端需要相同的底層資源)。依賴注入同樣適用于構(gòu)造函數(shù)、靜態(tài)工廠(第1項(xiàng))和構(gòu)建器(第2項(xiàng))。

??將資源工廠傳遞給構(gòu)造函數(shù)就會(huì)變成一個(gè)有用的模式。工廠是一個(gè)對(duì)象，通過(guò)重復(fù)調(diào)用這個(gè)工廠可以創(chuàng)建某個(gè)類型的實(shí)例對(duì)象。這些就是工廠方法模式 [Gamma95]。Java 8中引入的Supplier 接口非常適合體現(xiàn)工廠。在輸入上采用Supplier 的方法通常應(yīng)該使用泛型(第31項(xiàng))約束工廠的類型參數(shù)，以允許客戶端傳入創(chuàng)建指定類型的任何子類型的工廠。例如，這是一種使用客戶提供的工廠生成馬賽克來(lái)生成每個(gè)圖塊的方法：

Mosaic create(Supplier tileFactory) { ... }

??盡管依賴注入極大地提高了靈活性和可測(cè)試性，但它可能會(huì)使大型項(xiàng)目更加混亂，這些項(xiàng)目通常包含數(shù)千個(gè)依賴項(xiàng)。通過(guò)使用依賴注入框架，例如Dagger [Dagger]，Guice [Guice]或Spring [Spring]，可以消除這種混亂。這些框架的使用超出了本書的范圍，但請(qǐng)注意，為手動(dòng)依賴注入而設(shè)計(jì)的API可以輕松地適用于這些框架。

??總之，如果有一個(gè)類依賴一個(gè)或多個(gè)底層資源的類，并且底層資源類影響了類的行為，不要使用單例或靜態(tài)實(shí)用程序類來(lái)實(shí)現(xiàn)它，并且不要讓類直接創(chuàng)建這些資源(do not use a singleton or static utility class to implement a class that depends on one or more underlying resources whose behavior affects that of the class)。相反，將資源或工廠傳遞給構(gòu)造函數(shù)(或靜態(tài)工廠或構(gòu)建器)。這種做法稱為依賴注入，將極大地增強(qiáng)類的靈活性，可重用性和可測(cè)試性。