Verhaltensmuster

Iterator

Iterator ist ein Verhaltensentwurfsmuster. Stellt ein Objekt dar, das sequenziellen Zugriff auf die Elemente eines Aggregatobjekts ermöglicht, ohne Beschreibungen der einzelnen Aggregatobjekte zu verwenden.

Beispielsweise können Elemente wie ein Baum, eine verknüpfte Liste, eine Hash-Tabelle und ein Array mithilfe eines Iterator-Objekts durchlaufen (und geändert) werden.

Die Iteration durch die Elemente erfolgt durch das Iteratorobjekt, nicht durch die Sammlung selbst. Dies vereinfacht die Schnittstelle und Implementierung der Sammlung und fördert eine logischere Trennung von Belangen.

Ein Merkmal eines vollständig implementierten Iterators besteht darin, dass der Code, der den Iterator verwendet, möglicherweise nichts über den Typ des iterierten Aggregats weiß.

Dieser Ansatz wird sehr häufig verwendet. Sie senden beispielsweise eine SQL-Abfrage an die Datenbank und als Antwort erhalten Sie einen Iterator (in SQL-Begriffen wird er normalerweise als Cursor bezeichnet). Und mit Hilfe des resultierenden Iterators können Sie Zeilen nacheinander aus der SQL-Antwort übernehmen.

Befehl

Ein Befehl ist ein Verhaltensentwurfsmuster, das in der objektorientierten Programmierung verwendet wird und eine Aktion darstellt. Das Befehlsobjekt enthält die Aktion selbst und ihre Parameter.

Um eine Methode aufzurufen, benötigen Sie normalerweise:

• Objektreferenz
• Methodenname (Methodenreferenz)
• Methodenparameterwerte
• Verweis auf den Kontext, der die verwendeten Objekte enthält

Alle diese Daten müssen in ein Objekt gepackt werden – Command ( Befehl ).

Aber das ist noch nicht alles: Schließlich muss jemand den Befehl ausführen. Dieses Muster umfasst also vier weitere Entitäten: Befehle ( command ), einen Befehlsempfänger ( receiver ), einen Befehlsaufrufer ( invoker ) und einen Client ( client ).

Ein ObjektBefehlkennt den Empfänger und ruft die Empfängermethode auf. Empfängerparameterwerte werden im Befehl gespeichert. Der Aufrufer (Aufrufer) weiß, wie der Befehl ausgeführt wird, und behält möglicherweise den Überblick über die ausgeführten Befehle. Der Aufrufer (Aufrufer) weiß nichts über einen bestimmten Befehl, er kennt nur die Schnittstelle.

Beide Objekte (das aufrufende Objekt und mehrere Befehlsobjekte) gehören zum Client-Objekt. Der Client entscheidet, welche Befehle er wann ausführt. Um einen Befehl auszuführen, übergibt es das Befehlsobjekt an den Aufrufer (Invoker).

Durch die Verwendung von Befehlsobjekten können Sie problemlos gemeinsam genutzte Komponenten erstellen, die Sie delegieren oder jederzeit Methodenaufrufe durchführen müssen, ohne die Klassenmethoden oder Methodenparameter kennen zu müssen.

Durch die Verwendung des Aufrufobjekts (Invoker) können Sie die ausgeführten Befehle aufzeichnen, ohne dass der Client dieses Abrechnungsmodell kennen muss (eine solche Abrechnung kann beispielsweise nützlich sein, um das Rückgängigmachen und Wiederherstellen von Befehlen zu implementieren).

Sie schreiben beispielsweise ein Programm, mit dem Sie verschiedene Aufgaben nach einem Zeitplan ausführen können. Einerseits verfolgt Ihr Programm Aufgaben und verwaltet deren Start, andererseits kann es mehrere Executoren haben, von denen jeder Befehle seines eigenen Typs ausführen kann. Zum Beispiel das Versenden von SMS, das Versenden von Briefen, das Versenden von Nachrichten an Telegram usw.

Beobachter

Beobachter ist ein Verhaltensentwurfsmuster. Implementiert einen Klassenmechanismus, der es einem Objekt dieser Klasse ermöglicht, Benachrichtigungen über Zustandsänderungen anderer Objekte zu empfangen und diese somit zu beobachten.

Klassen, die von anderen Klassen abonniert werden, werden Subjekte genannt , und abonnierende Klassen werden Observer genannt .

Bei der Implementierung des Observer-Musters werden üblicherweise die folgenden Klassen verwendet:

• Observable – eine Schnittstelle, die Methoden zum Hinzufügen, Entfernen und Benachrichtigen von Beobachtern definiert;
• Beobachter – die Schnittstelle, über die der Beobachter die Benachrichtigung erhält;
• ConcreteObservable ist eine konkrete Klasse, die die Observable- Schnittstelle implementiert .
• ConcreteObserver ist eine konkrete Klasse, die die Observer- Schnittstelle implementiert .

Das Observer-Muster wird verwendet, wenn das System:

• es gibt mindestens ein Objekt, das Nachrichten sendet;
• Es gibt mindestens einen Empfänger von Nachrichten, deren Anzahl und Zusammensetzung sich während der Ausführung der Anwendung ändern kann.
• vermeidet eine starke Kopplung interagierender Klassen.

Dieses Muster wird häufig in Situationen verwendet, in denen der Absender von Nachrichten kein Interesse daran hat, was die Empfänger mit den ihnen bereitgestellten Informationen machen.

Besucher

Besucher ist ein Verhaltensentwurfsmuster, das eine Operation beschreibt, die an Objekten anderer Klassen ausgeführt wird. Bei einem Besucherwechsel besteht keine Notwendigkeit, die betreuten Klassen zu ändern.

Die Vorlage demonstriert die klassische Technik zur Wiederherstellung verlorener Typinformationen, ohne auf Double-Dispatching-Downcast zurückgreifen zu müssen.

Sie müssen einige getrennte Vorgänge für eine Reihe von Objekten ausführen, aber Sie müssen vermeiden, deren Code zu verunreinigen. Und es besteht weder die Möglichkeit noch den Wunsch, den Typ jedes Knotens abzufragen und den Zeiger auf den richtigen Typ umzuwandeln, bevor die gewünschte Operation ausgeführt wird.

Die Vorlage sollte verwendet werden, wenn:

• Es gibt verschiedene Objekte unterschiedlicher Klassen mit unterschiedlichen Schnittstellen, an denen jedoch Operationen ausgeführt werden müssen, die von bestimmten Klassen abhängen.
• an der Struktur müssen verschiedene Operationen durchgeführt werden, die die Struktur komplizieren;
• Oft werden neue Operationen an der Struktur hinzugefügt.

Vermittler

Mediator ist ein Verhaltensentwurfsmuster, das die Interaktion mehrerer Objekte ermöglicht und gleichzeitig eine lose Kopplung aufrechterhält und die Notwendigkeit vermeidet, dass Objekte explizit aufeinander verweisen.

Mit dem Mediator-Muster können Sie die Interaktion vieler Objekte sicherstellen und gleichzeitig eine lose Kopplung bilden, sodass Objekte nicht explizit aufeinander verweisen müssen.

Der Mediator definiert eine Schnittstelle zum Informationsaustausch mit ObjektenKollegen, Ein bestimmter Vermittler koordiniert die Aktionen von ObjektenKollegen.

Jede Colleague- Klasse kennt ihr ObjektVermittlerAlle Kollegen tauschen Informationen nur mit einem Vermittler aus, in seiner Abwesenheit müssten sie Informationen direkt austauschen.

KollegenSenden Sie Anfragen an den Reseller/span> und empfangen Sie Anfragen von ihm. Der Mediator setzt kooperatives Verhalten um, indem er jede Anfrage an einen oder mehrere weiterleitetKollegen.