クラスが内部的に1つ以上のリソースに依存し、そのリソースがクラスの動作に影響を与える場合、シングルトンと静的ユーティリティクラスは使用しないことをお勧めします。

これらのリソースをクラスが直接作成することも避け、代わりに必要なリソースをコンストラクターに渡すのが適切です。依存性注入を使用することで、クラスの柔軟性、再利用性、テストのしやすさを向上させることができます。

例

静的ユーティリティクラスを使用した例

public class SpellChecker {

    private static final Lexicon dictionary = new Lexicon();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        // dictionaryを使用したロジック
    }

    public static List suggestions(String typo) {
        // dictionaryを使用したロジック
    }

このユーティリティクラスは、1つの辞書のみを使用することを前提としています。しかし現実には、辞書は言語ごとに別々にあることが多く、特殊な語彙用の辞書を別に用意する場合もあります。

シングルトンを使用した例

public class SpellChecker {

    private final Lexicon dictionary = new Lexicon();

    public static SpellChecker INSTANCE = new SpellChecker();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        // dictionaryを使用したロジック
    }

    public static List suggestions(String typo) {
        // dictionaryを使用したロジック
    }

シングルトンも同様に、1つの辞書のみを使用することを前提としているため、上記のような欠点が発生します。

解決策1 - フィールドからfinalキーワードを削除する。

public class SpellChecker {

    private Lexicon dictionary = new Lexicon();

    public static SpellChecker INSTANCE = new SpellChecker();

    private SpellChecker() {
    }

    public static void changeDictionary(Lexicon dictionary) {
        this.dictionary = dictionary;
    }

    public static boolean isValid(String word) {
        // dictionaryを使用したロジック
    }

    public static List suggestions(String typo) {
        // dictionaryを使用したロジック
    }

静的ユーティリティクラスまたはシングルトンクラスのdictionaryについて、finalキーワードを削除し、外部からdictionaryを別の辞書に置き換えるように設計することもできます。しかし、この方法は使用が難しく、マルチスレッド環境では同時性問題が発生する可能性があります。

解決策2 - 依存性注入を使用する。

public class SpellChecker {

    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = dictionary;
    }

    public static boolean isValid(String word) {
        // dictionaryを使用したロジック
    }

    public static List suggestions(String typo) {
        // dictionaryを使用したロジック
    }

上記の例から、静的クラスとシングルトンは、内部的なリソースに依存してはならないことがわかります。つまり、内部リソースは外部から注入されることが望ましいということです。

依存性注入を使用したクラスは、finalキーワードのおかげで不変性を保証することができ、複数のリソースインスタンスをサポートするという利点があります。 また、依存性注入は、コンストラクターだけでなく、静的ファクトリやビルダーでも適用できます。

依存性注入は、単にリソースそのものを渡す方法もありますが、リソースファクトリを渡す方法もよく使用されます。ファクトリとは、呼び出されるたびに特定のタイプのインスタンスを繰り返し作成するオブジェクトのことです。この方法はファクトリメソッドパターンと呼ばれ、Java 8ではSupplierがファクトリを表す完全な例です。

public static List create(Supplier generator) {
    ...

主に限定ワイルドカードタイプを使用して、ファクトリのタイプパラメーターを制限します。この方法を使用すると、クライアントは、指定したタイプのサブタイプであれば、どのようなファクトリでも渡すことができます。

依存性注入は、柔軟性とテストのしやすさを向上させますが、依存関係が非常に多いプロジェクトでは、コストがかかる可能性があります。このような場合は、依存性注入フレームワーク（Dagger、Guice、Springなど）を使用することでコストを削減できます。

出典

• エフェクティブ・Java
• https://catsbi.oopy.io/d7f3a636-b613-453b-91c7-655d71fda2b1