Wenn eine Klasse intern von einer oder mehreren Ressourcen abhängt und diese Ressourcen das Klassenverhalten beeinflussen, sollten Sie keine Singleton- und statischen Utility-Klassen verwenden.

Diese Ressourcen sollten auch nicht von der Klasse selbst erstellt werden. Stattdessen sollten Sie die benötigten Ressourcen an den Konstruktor übergeben. Durch die Injektion abhängiger Objekte können Sie die Flexibilität, Wiederverwendbarkeit und Testbarkeit der Klasse verbessern.

Beispiel

Beispiel für die Verwendung einer statischen Utility-Klasse

public class SpellChecker {

    private static final Lexicon dictionary = new Lexicon();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        // Logik unter Verwendung des Wörterbuchs
    }

    public static List suggestions(String typo) {
        // Logik unter Verwendung des Wörterbuchs
    }

Diese Utility-Klasse geht davon aus, dass nur ein Wörterbuch verwendet wird. In der Praxis gibt es jedoch separate Wörterbücher für verschiedene Sprachen und sogar separate Wörterbücher für spezielle Vokabeln.

Beispiel für die Verwendung einer Singleton-Klasse

public class SpellChecker {

    private final Lexicon dictionary = new Lexicon();

    public static SpellChecker INSTANCE = new SpellChecker();

    private SpellChecker() {
    }

    public static boolean isValid(String word) {
        // Logik unter Verwendung des Wörterbuchs
    }

    public static List suggestions(String typo) {
        // Logik unter Verwendung des Wörterbuchs
    }

Auch Singleton-Klassen gehen davon aus, dass nur ein Wörterbuch verwendet wird, daher tritt der oben genannte Nachteil auf.

Lösung 1 - Entfernen Sie das final-Schlüsselwort aus dem Feld.

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) {
        // Logik unter Verwendung des Wörterbuchs
    }

    public static List suggestions(String typo) {
        // Logik unter Verwendung des Wörterbuchs
    }

Sie können das final-Schlüsselwort für das Wörterbuch in einer statischen Utility-Klasse oder einer Singleton-Klasse entfernen und das Wörterbuch von außen durch ein anderes Wörterbuch ersetzen. Diese Methode ist jedoch selbst schwer zu verwenden und kann in einer Multithread-Umgebung zu Parallelitätsproblemen führen.

Lösung 2 - Verwenden Sie die Injektion abhängiger Objekte.

public class SpellChecker {

    private final Lexicon dictionary;

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

    public static boolean isValid(String word) {
        // Logik unter Verwendung des Wörterbuchs
    }

    public static List suggestions(String typo) {
        // Logik unter Verwendung des Wörterbuchs
    }

Anhand des obigen Beispiels können Sie erkennen, dass statische Klassen und Singleton-Klassen nicht von internen Ressourcen abhängig sein sollten. Das bedeutet, dass interne Ressourcen am besten von außen injiziert werden.

Eine Klasse, die die Injektion abhängiger Objekte verwendet, bietet durch das final-Schlüsselwort die Garantie der Unveränderlichkeit und unterstützt mehrere Ressourceninstanzen. Die Injektion abhängiger Objekte kann nicht nur im Konstruktor, sondern auch in statischen Fabriken und Buildern angewendet werden.

Bei der Injektion abhängiger Objekte können Sie die Ressourcen selbst übergeben, aber es wird auch häufig verwendet, eine Ressourcenfabrik zu übergeben. Eine Fabrik ist ein Objekt, das bei jedem Aufruf eine Instanz eines bestimmten Typs erstellt. Diese Methode wird als Factory-Method-Pattern bezeichnet, und Supplier in Java 8 ist ein perfektes Beispiel für die Darstellung einer Fabrik.

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

Normalerweise wird ein eingeschränkter Platzhaltertyp verwendet, um den Typparameter der Fabrik einzuschränken. Mit dieser Methode kann der Client der Fabrik jeden Untertyp des von ihm angegebenen Typs übergeben.

Die Injektion abhängiger Objekte verbessert die Flexibilität und Testbarkeit, aber bei Projekten mit vielen Abhängigkeiten kann dies sehr kostspielig sein. In solchen Fällen können Sie ein Framework für abhängige Objekte (Dagger, Guice, Spring usw.) verwenden, um die Kosten zu senken.

Quelle

• Effektives Java
• https://catsbi.oopy.io/d7f3a636-b613-453b-91c7-655d71fda2b1