Verhaltensmuster, Teil 2

2.1 Staat

Zustand ist ein Verhaltensentwurfsmuster. Es wird in den Fällen verwendet, in denen das Objekt während der Ausführung des Programms sein Verhalten abhängig von seinem Zustand ändern muss.

Das Muster besteht aus 3 Blöcken:

Kontext ist eine Klasse, deren Objekte ihr Verhalten je nach Zustand ändern sollen.

State ist die Schnittstelle, die jeder der konkreten Staaten implementieren muss. Über diese Schnittstelle interagiert das Kontextobjekt mit dem Status, indem es Methodenaufrufe an ihn delegiert. Die Schnittstelle sollte Mittel zur Rückmeldung an das Objekt enthalten, dessen Verhalten geändert werden soll.

Hierzu wird ein Ereignis verwendet (Muster Publisher – Subscriber). Dies ist notwendig, um das Statusobjekt während der Programmausführung bei auftretenden Ereignissen zu ersetzen. Es kann Fälle geben, in denen der Kontext selbst das Statusobjekt regelmäßig nach einem Übergang abfragt.

ConcreteState1, ConcreteState2 – Klassen konkreter Zustände. Sollte Informationen darüber enthalten, unter welchen Bedingungen und in welche Zustände das Objekt vom aktuellen Zustand übergehen kann. Beispielsweise kann ein Objekt von ConcreteState1 zu ConcreteState2 und ConcreteState3 wechseln und von ConcreteState2 zurück zu ConcreteState1 und so weiter. Das Objekt eines von ihnen muss beim Erstellen den Kontext enthalten.

Sie schreiben beispielsweise ein Spiel, in dem eine Figur rennen, schwimmen und fliegen kann. Wenn Ihr Charakter ins Wasser gelangt ist, ist es sinnvoll, sein Verhalten im Wasser einzuschränken: Jetzt kann er nicht mehr schießen, hat aber noch einige Aktionen: vorwärts, rechts, links schwimmen usw.

Der Zustand Ihres Charakters kann durch ein State-Objekt beschrieben werden, das über aufrufbare Methoden verfügt, die etwas bewirken. Und nachdem Ihr Charakter ins Wasser gelangt ist, ändern Sie einfach den Verweis auf ein anderes darin enthaltenes Statusobjekt – und es ändert seinen Status.

2.2 Strategie

Strategie ist ein Verhaltensentwurfsmuster zum Definieren einer Familie von Algorithmen, zum Kapseln jedes einzelnen und zum Austauschen derselben. Dadurch können Sie einen Algorithmus auswählen, indem Sie die entsprechende Klasse definieren.

Mit dem Strategiemuster können Sie den ausgewählten Algorithmus unabhängig von den Clientobjekten ändern, die ihn verwenden.

Mit dem Strategiemuster können Sie je nach Kontext unterschiedliche Geschäftsregeln oder Algorithmen verwenden. Es wird in Fällen verwendet, in denen abhängig vom aktuellen Zustand des Systems (oder seiner Umgebung) unterschiedliche Algorithmen an derselben Stelle verwendet werden müssen.

Starke Seiten:

• Durch die Kapselung der Implementierung verschiedener Algorithmen wird das System unabhängig von möglichen Änderungen der Geschäftsregeln.
• Aufrufen aller Algorithmen auf eine Standardmethode;
• keine Schalter und/oder bedingten Anweisungen verwenden.

Dieses Muster ähnelt in gewisser Weise dem Zustandsmuster, allerdings liegt hier der Schwerpunkt nicht auf dem Zustand, sondern auf dem Verhalten. Nehmen wir an, ein Charakter in Ihrem Spiel kann die Waffe wechseln. Dann können Sie beim Waffenwechsel einfach den Verweis auf das Objekt ändern, das die Funktionsweise dieser Waffe beschreibt.

2.3 Vorlagenmethode

Abstrakte Klasse (abstrakte Klasse) – definiert die abstrakten Operationen, die in den Erben ersetzt werden, um die Schritte des Algorithmus zu implementieren; implementiert eine Vorlagenmethode, die das Grundgerüst des Algorithmus definiert. Die Vorlagenmethode ruft die ersetzten und andere in der Abstract-Klasse definierten Operationen auf.

Konkrete Klasse (konkrete Klasse) – implementiert die ersetzten Operationen auf die für die Implementierung erforderliche Weise. Die Concrete-Klasse geht davon aus, dass die invarianten Schritte des Algorithmus in der AbstractClass ausgeführt werden.

Dieses Muster wird bei Bedarf häufig verwendet:

• Einmalige Verwendung des invarianten Teils des Algorithmus, wobei der sich ändernde Teil im Ermessen der Erben liegt.
• Lokalisierung und Isolierung von Code, der mehreren Klassen gemeinsam ist, um Duplikate zu vermeiden.
• Erlauben Sie Erben, Code nur an bestimmten Stellen zu erweitern.

Ja, dieses Muster beschreibt die Verwendung eines Paares: einer abstrakten Klasse und ihrer Implementierung.

2.4 Verantwortungskette

Die Verantwortungskette ist ein Verhaltensentwurfsmuster, das darauf abzielt, Verantwortungsebenen in einem System zu organisieren.

Die Vorlage wird für den Einsatz unter folgenden Bedingungen empfohlen:

• im entwickelten System gibt es eine Gruppe von Objekten, die Nachrichten eines bestimmten Typs verarbeiten können;
• alle Nachrichten müssen von mindestens einem Systemobjekt verarbeitet werden;
• Nachrichten im System werden nach dem Schema „selbst verarbeiten oder an andere weitergeben“ verarbeitet, d. h. einige Nachrichten werden auf der Ebene verarbeitet, auf der sie empfangen wurden, während andere an Objekte einer anderen Ebene weitergeleitet werden.

2,5 Erinnerung

Keeper (Memento) ist ein Verhaltensentwurfsmuster, mit dem Sie den internen Zustand eines Objekts reparieren und speichern können, ohne die Kapselung zu verletzen, sodass dieser Zustand später wiederhergestellt werden kann.

Das Guardian-Muster wird verwendet, wenn:

• es ist notwendig, eine Momentaufnahme des Zustands des Objekts (oder eines Teils davon) für die spätere Wiederherstellung zu speichern;
• Die direkte Schnittstelle zum Abrufen des Status eines Objekts legt Implementierungsdetails offen und unterbricht die Objektkapselung.