Detaillierte Erläuterung der IOC-Inversion von Kontrollbeispielen

Inversion of Control (IoC) ist ein wichtiges Merkmal des Frameworks und kein spezieller Begriff für objektorientierte Programmierung. Es hat nichts mit Dependency Injection (DI) und Dependency Lookup (Dependency Lookup) zu tun.

Entwickler, die Spring verwendet haben, sollten alle die IOC-Inversion-of-Control-Funktion verstehen. Wenn Sie zum ersten Mal lernen, sollten Sie alle wissen, dass die Abhängigkeitsinjektion zum Implementieren von IOC-Funktionen verwendet wird ​mit IOC-Inversion der Steuerung.

Abhängigkeitsinjektion zur Implementierung von IOC

Abhängigkeitsinjektion ist die grundlegendste Implementierungsmethode von IOC und das am häufigsten verwendete objektorientierte Design die Wege. Wie Abhängigkeiten eingefügt werden, um die Umkehrung des Kontrolleffekts zu erreichen, beginnen Sie mit einem Beispiel:

public interface UserQueue {void add(User user);void remove(User user);

    User get();

}public abstract class AbstractUserQueue implements UserQueue {protected LinkedList<User> queue = new LinkedList<>();

    @Overridepublic void add(User user) {
        queue.addFirst(user);
    }

    @Overridepublic void remove(User user) {
        queue.remove(user);
    }

    @Overridepublic abstract User get();

}public class UserFifoQueue extends AbstractUserQueue {public User get() {return queue.getLast();
    }

}public class UserLifoQueue extends AbstractUserQueue {public User get() {return queue.getFirst();
    }

}

UserQueue Die Schnittstelle definiert öffentliche Methoden zum Speichern von Benutzerobjekten in einer Warteschlange. AbstractUserQueue则是为后续的继承类，提供了一些公用的方法实现。最后的UserFifoQueue und UserLifoQueue，则是分别实现了FIFO 和 LIFO 队列。

Dies ist ein effektiver Weg, um Unterklassenpolymorphismus zu erreichen.

Durch die Erstellung einer Client-Klasse, die vom abstrakten Typ UserQueue abhängt (in der DI-Terminologie auch als Dienst bezeichnet), können zur Laufzeit verschiedene Implementierungen eingefügt werden, ohne dass der Code, der die Client-Klasse verwendet, umgestaltet werden muss:

public class UserProcessor {private UserQueue userQueue;public UserProcessor(UserQueue userQueue) {this.userQueue = userQueue;
    }public void process() {// process queued users here    }

}

UserProcessor展示了依赖注入确实是IOC的一种方式。

Wir können die Abhängigkeit von der Warteschlange erhalten, indem wir sie direkt im Konstruktor im UserProcessor durch einige fest codierte Methoden wie eine neue Operation instanziieren . . Dabei handelt es sich jedoch um typische Code-Hard-Programmierung, die eine starke Kopplung zwischen Client-Klassen und ihren Abhängigkeiten einführt und die Testbarkeit erheblich verringert.

Diese Klasse deklariert ihre Abhängigkeit von der abstrakten Klasse UserQueue im Konstruktor. Das heißt, Abhängigkeiten werden nicht mehr durch die Verwendung von „new“ im Konstruktor verwaltet, sondern stattdessen extern eingefügt, entweder mithilfe eines Dependency-Injection-Frameworks oder mithilfe des Factory- oder Builders-Musters.

Durch die Abhängigkeitsinjektion liegt die Steuerung der Client-Klassenabhängigkeiten nicht mehr in diesen Klassen, sondern erfolgt im Injektor, siehe folgenden Code:

public static void main(String[] args) {
     UserFifoQueue fifoQueue = new UserFifoQueue();
     fifoQueue.add(new User("user1"));
     fifoQueue.add(new User("user2"));
     fifoQueue.add(new User("user3"));
     UserProcessor userProcessor = new UserProcessor(fifoQueue);
     userProcessor.process();
}

Die obige Methode hat die erwarteten Ergebnisse erzielt und die UserLifoQueue的注入也简单明了。

Beobachtermodus-Implementierung IOC

wird direkt durch implementiert Der Beobachtermodus IOC ist ebenfalls eine gängige intuitive Methode. Im Großen und Ganzen wird IOC durch Beobachter implementiert. Das Beobachtermuster wird normalerweise verwendet, um die Zustandsänderungen von Modellobjekten im Kontext von Modellansichten zu verfolgen.

In einer typischen Implementierung sind ein oder mehrere Beobachter an ein beobachtbares Objekt (in der Musterterminologie auch Subjekt genannt) gebunden, beispielsweise durch Aufrufen der Methode addObserver. Sobald die Bindung zwischen dem Beobachteten und dem Beobachter definiert ist, lösen Änderungen im Zustand des Beobachteten den Aufruf des Beobachters aus. Schauen Sie sich das folgende Beispiel an:

public interface SubjectObserver {void update();

}

Wenn sich der Wert ändert, wird der Aufruf an den oben genannten sehr einfachen Beobachter ausgelöst. In realen Situationen werden normalerweise APIs mit umfangreicheren Funktionen bereitgestellt, z. B. zum Ändern von Instanzen oder zum Speichern alter und neuer Werte. Diese erfordern jedoch keine Beachtung des Aktions- (Verhaltens-) Modus, sodass die Beispiele hier so einfach sind wie möglich.

Unten ist eine Beobachterklasse angegeben:

public class User {private String name;private List<SubjectObserver> observers = new ArrayList<>();public User(String name) {this.name = name;
    }public void setName(String name) {this.name = name;
        notifyObservers();
    }public String getName() {return name;
    }public void addObserver(SubjectObserver observer) {
        observers.add(observer);
    }public void deleteObserver(SubjectObserver observer) {
        observers.remove(observer);
    }private void notifyObservers(){
        observers.stream().forEach(observer -> observer.update());
    }

}

Wenn in der Benutzerklasse ihr Status durch die Setter-Methode geändert wird, wird ein gebundener Aufruf ausgelöst zu seinem Beobachter.

Verwenden Sie Themenbeobachter und Themen. Die folgenden Beispiele geben die Beobachtungsmethode an:

public static void main(String[] args) {
    User user = new User("John");
    user.addObserver(() -> System.out.println("Observable subject " + user + " has changed its state."));
    user.setName("Jack");
}

Immer wenn der Status des Benutzerobjekts durch die Setter-Methode geändert wird Der Beobachter wird benachrichtigt und eine Nachricht wird auf der Konsole ausgegeben. Bisher wurde ein einfacher Anwendungsfall des Observer-Musters angegeben. Durch diesen scheinbar einfachen Anwendungsfall verstehen wir jedoch, wie die Umkehrung der Kontrolle in dieser Situation erreicht werden kann.

Im Beobachtermodus spielt das Theme die Rolle der „Framework-Ebene“, die vollständig steuert, wann und wo wessen Aufruf ausgelöst wird. Die Initiative von Beobachtern wird delegiert, da Beobachter nicht steuern können, wann sie aufgerufen werden (sofern sie bei einem Thema registriert sind). Das bedeutet, dass wir tatsächlich herausfinden können, wo die Umkehrung der Kontrolle stattfindet – wenn der Beobachter an das Subjekt gebunden ist:

user.addObserver(() -> System.out.println("Observable subject " + user + " has changed its state."));

上述用例，简要说明了为什么观察者模式是实现IoC的一种非常简单的方式。正是以这种分散式设计软件组件的形式，使得控制得以发生反转。

 

模板方法模式实现IOC

模板方法模式实现的思想是在一个基类中通过几个抽象方法来定义一个通用的算法，然后让子类提供具体的实现，这样保证算法结构不变。

我们可以应用这个思想，定义一个通用的算法来处理领域实体，看例子：

public abstract class EntityProcessor {public final void processEntity() {
        getEntityData();
        createEntity();
        validateEntity();
        persistEntity();
    }protected abstract void getEntityData();protected abstract void createEntity();protected abstract void validateEntity();protected abstract void persistEntity();

}

processEntity() 方法是个模板方法，它定义了处理实体的算法，而抽象方法代表了算法的步骤，它们必须在子类中实现。通过多次继承 EntityProcessor 并实现不同的抽象方法，可以实现若干算法版本。

虽然这说清楚了模板方法模式背后的动机，但人们可能想知道为什么这是 IOC 的模式。

典型的继承中，子类调用基类中定义的方法。而这种模式下，相对真实的情况是：子类实现的方法(算法步骤)被基类的模板方法调用。因此，控制实际是在基类中进行的，而不是在子类中。

总结：

依赖注入：从客户端获得依赖关系的控制不再存在于这些类中。它存由底层的注入器 / DI 框架来处理。

观察者模式：当主体发生变化时，控制从观察者传递到主体。

模板方法模式：控制发生在定义模板方法的基类中，而不是实现算法步骤的子类中。

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der IOC-Inversion von Kontrollbeispielen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!