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

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

// 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) { ... }
}

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

// 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) { ... }
}

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

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

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

// 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) { ... }
}

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

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

Mosaic create(Supplier tileFactory) { ... }

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

??總之，如果有一個類依賴一個或多個底層資源的類，并且底層資源類影響了類的行為，不要使用單例或靜態(tài)實用程序類來實現(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)建器)。這種做法稱為依賴注入，將極大地增強類的靈活性，可重用性和可測試性。