Der Beobachtermodus (manchmal als Publish-Subscribe-Modus, Model-View-Modus, Quelllistener-Modus oder Slave-Modus bezeichnet) ist eine Art Software-Design-Modus. In diesem Modus verwaltet ein Zielobjekt alle Beobachterobjekte, die davon abhängen, und gibt aktiv Benachrichtigungen aus, wenn sich sein Zustand ändert. Dies wird normalerweise erreicht, indem die Methoden jedes Beobachters aufgerufen werden. Dieses Muster wird normalerweise zur Implementierung von Ereignisverarbeitungssystemen verwendet.
Der Beobachtermodus trennt den Beobachter perfekt vom beobachteten Objekt. Beispielsweise kann die Benutzeroberfläche als Beobachter verwendet werden, und die Geschäftsdaten sind der Beobachter. Die Benutzeroberfläche beobachtet die Änderungen in den Geschäftsdaten. Nachdem die Änderungen in den Daten entdeckt wurden, wird sie auf der Schnittstelle angezeigt. Ein Prinzip des objektorientierten Designs ist, dass sich jede Klasse im System auf eine Funktion konzentriert, nicht auf andere Aspekte. Eine Person macht nur eine Sache und macht es gut. Der Beobachtermodus zeichnet klare Grenzen zwischen Modulen und verbessert die Wartbarkeit und Wiederverwendbarkeit der Anwendung.
Das Beobachter-Entwurfsmuster definiert eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, sodass sich alle Objekte, die davon abhängen, benachrichtigt und automatisch aktualisiert werden, wenn sich der Zustand eines Objekts ändert.
Implementierungsmethode:
Es gibt viele Möglichkeiten, das Beobachtermuster zu implementieren, und im Grunde muss das Muster zwei Rollen enthalten: den Beobachter und das beobachtete Objekt. In dem Beispiel jetzt sind die Geschäftsdaten das zu beobachtende Objekt und die Benutzeroberfläche ist der Beobachter. Es besteht eine logische Beziehung zwischen dem Beobachter und dem Beobachter. Wenn sich der Beobachter ändert, wird der Beobachter solche Änderungen beobachten und entsprechend reagieren. Wenn ein solcher Beobachtungsprozess zwischen der Benutzeroberfläche und den Geschäftsdaten verwendet wird, kann sichergestellt werden, dass die Grenze zwischen der Schnittstelle und den Daten gezogen wird. Unter der Annahme, dass sich die Bedürfnisse der Anwendung ändern, muss die Leistung der Schnittstelle geändert werden. Es muss nur eine Benutzeroberfläche rekonstruiert werden, und die Geschäftsdaten müssen sich nicht ändern.
1 Beobachter
(Beobachter) registriert sich in das Subjekt, und das beobachtete Objekt speichert den Beobachter in einem Behälter.
2.. Beobachtet werden
Das beobachtete Objekt hat eine gewisse Änderung (wie in der Abbildung in Somechange gezeigt), und alle registrierten Beobachter werden aus dem Behälter erhalten und den Beobachter über die Änderung informiert.
3.. Beobachtung widerrufen
Der Beobachter fordert den Beobachter auf, die Beobachtung abzusagen und den Beobachter aus dem Behälter entfernt.
Wenn sich ein Beobachter in den Behälter des Beobachters registriert, sollte der Beobachter nicht nach dem spezifischen Typ des Beobachters fragen, sondern die Schnittstelle des Beobachters verwenden. Dieser Vorteil ist: Angenommen, es gibt andere Beobachter im Programm, solange dieser Beobachter auch von derselben Schnittstelle implementiert wird. Eine beobachtete Person kann mehreren Beobachtern entsprechen. Wenn sich die beobachtete Person ändert, kann er alle Beobachter einzeln benachrichtigen. Basierend auf Schnittstellen und nicht auf spezifischen Implementierungen bietet dies eine größere Flexibilität für Programme.
Demonstrationscode:
Definieren Sie die Rolle der Abstract -Klasse, die beobachtet werden soll:
Paket test.edu.mainrole; Import Java.util.ArrayList; public Abstract Class Absrole {private arrayList <Iobserver> list = new ArrayList <Iobserver> (); public void add (iobserver observer) {list.add (Beobachter); } public void delete (iobserver observer) {list.remove (Beobachter); } public void nodifyObServers (String NewState) {für (iObserver observer: list) {observer.update (newState); }}} Beobachtete Rollenunterklasse:
Paket test.edu.mainrole; Die Rolle der öffentlichen Klasse erweitert Abrole {privater String -Status; public String getState () {Return State; } public void Change (String nupdate) {state = nupdate; this.nodifyObservers (Zustand); }} Definieren Sie die Observer -Schnittstelle:
Paket test.edu.mainrole; public interface iobserver {public void Update (String NewState); } Spezifische Beobachter:
Paket test.edu.mainrole; öffentliche Klasse Observerobj1 implementiert IOBServer {private String observerstate; @Override public void update (String State) {observerState = STAAT; System.out.println ("Der Status des Beobachters 1 lautet:" + Beobachterstate); }} Paket test.edu.mainrole; öffentliche Klasse ObserveroBJ2 implementiert IOBSERVER {private String observerstate; @Override public void update (String State) {observerState = STAAT; System.out.println ("Der Status von Observer 2 lautet:" + Beobachterstate); }} Test Client:
Paket test.edu.mainrole; öffentliche Klasse Client { / ** * @param args * / public static void main (string [] args) {rollens subjekt = new rollen (); IOBServer Observer1 = new ObserverObj1 (); IOBServer Observer2 = new ObserverObj2 (); Betreff.Add (Observer1); Betreff.Add (Observer2); Betreff.Change ("Update!"); }} Auslaufergebnisse:
Der Zustand des Beobachters 1 ist: Update! Der Zustand des Beobachters 2 lautet: Update!
Das obige dreht sich alles um diesen Artikel, und ich hoffe, es wird Sie zum Lernen inspirieren.