Eines der bekanntesten Design Patterns ist das State Pattern. Im Folgenden möchte ich euch dieses nahe bringen und erklären, was meine wütende Freundin damit zu tun hat. Das ganze Beispiel ist in Java umgesetzt, kann aber in jeder objektorientierten Programmiersprache implementiert werden.
Wann brauche ich das State Pattern? Das State Pattern kann verwendet werden, wenn man ein Objekt hat, welches sich je nach Zustand/Modus in seinen Methoden anders verhalten soll.
Für dieses Beispiel habe ich meine Freundin mal in eine Klasse gesteckt (Ich hoffe das gibt keinen Ärger). Meine Freundin hat nun fünf Methoden: komplimentBekommen, frechenKommentarBekomme, geburtstagVergessen, essenKochen, mitMaxSprechen (das bin ich). Die Methode geburtstagVergessen würde in einer sauberen implementierung nicht in der Klasse Freundin stecken, dass wurde zur vereinfachung des Beispiels hier mit ergänzt.
Meine Freundin hat nun drei Zustände: Happy, Angry und richtigAngry. Etwas dazwischen gibt es meistens nicht. Ihr Zustand kann sich nun je nach Ereignis verändern. Beim Ausführen der komplimentBekommen Methode wird der Zustand Happy ausgelöst, bei frechenKommentarBekommen der Zustand Angry und bei der Methode geburtstagVergessen der Zustand RichtigAngry.
Das Beispiel ist stark vereinfacht, in der realen Welt würde der Zustand z.B. nicht wieder auf Happy wechseln, wenn ich Ihren Geburtstag vergessen habe, ihr aber 5 Minuten später ein Kompliment gebe. Nun haben wir noch zwei weitere Methoden „mitMaxSprechen“ und „essenMachen“. Der Trick beim State Pattern ist, dass sich das verhalten der jeweiligen Methode je nach Zustand ändert.
Wie in der Realität wird meine Freundin nun anders mit mir sprechen, wenn sie Happy, oder Angry ist.
Wie implementiere ich das Ganze?
Es wird ein Zustand Interface benötigt. Dann wird für jeden benötigten Zustand eine Zustandsklasse angelegt, die das Zustandsinterface implementieren. In den Zustandsklassen werden dann die Methoden überschrieben, welche sich im jeweiligen Zustand anders verhalten sollen. In unserem Fall wären das mitMaxSprechen und essenKochen. Hier wird dann auch die unterschiedliche Logik für den jeweiligen Zustand ausimplementiert.
Die Ausgaben verhalten sich also wie folgt:
mitMaxSprechen
Im Happy Zustand -> an jedem Satz wird ein 🙂 ergänzt.
Im Angry Zustand -> Es werden !!! und ein „Idiot“ ergänzt.
Im RichtigAngry Zustand -> Der Input String wird durch ein „…“ ersetzt.
essenKochen
Im Happy Zustand -> Es wird für zwei Personen inkl. Nachtisch gekocht.
Im Angry Zustand -> Es wird für eine Person gekocht (nicht für mich)
Im RichtigAngry Zustand -> Es wird eine Exception geworfen. „In diesem Zustand wird höchstens vor Wut gekocht“.
Fazit
Das State Pattern ist ein sehr mächtiges Design Pattern, wenn man wirklich den Fall hat, dass sein Objekt mehrere Zustände mit einer unterschiedlichen Implementierung aufweist. Man sollte jedoch prüfen, ob das State Pattern wirklich notwendig und die richtige Lösung ist. Hat man z.B. nur zwei mögliche Zustände mit nur minimal unterschiedlicher Ausprägung, kann ein State Pattern schnell zum Overengineering führen und die eigentlich simple Lösung komplexer machen als nötig. Es lohnt sich ebenfalls einen Blick auf das Strategy Pattern zu werfen. Dieses unterscheidet sich nur leicht vom State Pattern, kann jedoch je nach Ausgangslage die bessere Lösung bieten.
Das Beispiel stammt aus einer Schulung über Design Patterns von uns. Für dich und deine Firma könnten Schulungen im Bereich der Softwareentwicklung ebenfalls interessant sein?
Kontaktiere uns gerne!
