Entwurfsmuster in PHP – Teil V
von Matthias Kannengiesser
Mithilfe der in Teil III und Teil IV dieser Reihe vorgestellten Erzeugungs- und Strukturmuster sind Sie in der Lage, effizient Objekte zu erzeugen und diese zu komplexen Strukturen zusammenzusetzen. Verhaltensmuster stellen die letzte Gruppe dar und sorgen für die Musterimplementierung. Diese Muster befassen sich mit dem Verhalten und der Interaktion der verschiedenen Objekte. Sie beschreiben dabei nicht nur die beteiligten Klassen und Objekte, sondern darüber hinaus auch die Art und Weise, wie diese zur Laufzeit miteinander interagieren.
Pattern: Chain of Responsibility (Zuständigkeitskette)
Ziel: Vermeidet die Koppelung des Auslösers einer Anfrage an seinen Empfänger, indem mehr als ein Objekt die Möglichkeit erhält, die Anfrage zu erledigen.
Auswirkungen: Das Pattern verkettet die empfangenen Objekte und leitet die Anfrage von Objekt zu Objekt, bis ein Objekt sie erledigt. Jeder Teilnehmer der Kette kennt lediglich seinen Nachfolger. Die Kettenstruktur ist dynamisch aufbaubar und änderbar. Es gibt keine Empfangsgarantie, Anfragen daher auch können unbehandelt bleiben.
Pattern: Command (Befehl)
Ziel: Kapselt einen Auftrag als Objekt.
Auswirkungen: Das Objekt, das eine Anfrage schickt, muss nicht wissen, wie diese abgearbeitet wird. Anfragen können in eine Warteschlange gestellt oder rückgängig gemacht werden. Anfragen können parametrisiert oder erweitert werden.
Pattern: Interpreter (Dolmetscher)
Ziel: Erstellt für eine gegebene Sprache eine Grammatik und interpretiert die Sätze in der Sprache.
Auswirkungen: Bestehende Grammatiken sind einfach zu ändern und zu erweitern. Die Regeln der Grammatik werden durch Klassen repräsentiert. Durch Anpassen der zugehörigen Klasse kann eine Regeländerung übernommen werden. Zusätzliche Operationen sind leicht hinzuzufügen.
Pattern: Iterator
Ziel: Ermöglicht sequenziellen Zugriff auf die Elemente eines Objekts, ohne dessen Struktur zu offenbaren.
Auswirkungen: Das Pattern vereinfacht die Schnittstelle des Aggregats. Ermöglicht die parallele Iteration des Aggregats. Ermöglicht unterschiedliche Arten der Iteration über dasselbe Aggregat.
Pattern: Mediator (Vermittler)
Ziel: Definiert ein Objekt, welches das Zusammenspiel einer Menge von Objekten in sich kapselt.
Auswirkungen: Vermittler fördern lose Koppelung, indem sie verhindern, dass Objekte aufeinander explizit Bezug nehmen. Sie ermöglichen ihnen, das Zusammenspiel der Objekte voneinander unabhängig zu variieren.
Pattern: Memento
Ziel: Erfasst und externalisiert den internen Zustand eines Objekts, ohne seine Kapselung zu verletzen, sodass das Objekt später in diesen Zustand zurückversetzt werden kann.
Auswirkungen: Externe Speicherung von Zuständen, ohne interne Details zu verraten. Performance-intensive Zustandswechsel.
Pattern: Subject/Observer (Beobachter)
Ziel: Definiert 1:n-Abhängigkeit zwischen Subjekt und Beobachterobjekten
Auswirkungen: Das Subjekt kann ohne Beobachter eingesetzt werden. Lose Koppelung zwischen Subjekt und Beobachtern. Einfache Operationen können kaskadierende Aktionen in den Beobachtern auslösen.
Pattern: State (Zustand)
Ziel: Ermöglicht es einem Objekt, sein Verhalten zu ändern, wenn sein interner Zustand sich ändert.
Auswirkungen: Zustandsabhängiges wird Verhalten in eine eigene Klassenhierarchie ausgelagert. Zustandsänderungen werden explizit durchgeführt. Relativ leichte Erweiterbarkeit.
Pattern: Strategy (Strategie)
Ziel: Definiert eine Familie von Algorithmen, kapselt jeden einzelnen und macht sie austauschbar.
Auswirkungen: Polymorphismus statt Fallunterscheidung (if-, elseif etc.). Auswahl verschiedener Implementationen desselben Verhaltens. Relativ leichte Erweiterbarkeit.
Pattern: Template-Methode (Schablonenmethode)
Ziel: Definiert die Schritte eines Algorithmus und überlässt die Implementierung der Schritte den Unterklassen.
Auswirkungen: Erhöht die Wiederverwendbarkeit von Code. Herausfaktorieren gemeinsamen Verhaltens.
Pattern: Visitor (Besucher)
Ziel: Fügt neue Operationen einer Objektstruktur hinzu und kapselt diese in einer Klasse.
Auswirkungen: Verhindert, dass zusammengehörige Operationen über mehrere Klassen verteilt sind. Ermöglicht Zugriff auf Daten, die ansonsten verborgen bleiben. Erschwert das Hinzufügen neuer Elemente zur Datenstruktur.
Was Entwurfsmuster nicht sind:
Für eine Vielzahl von Entwicklern sind Entwurfsmuster aus der Anwendungsentwicklung nicht mehr wegzudenken. Sollten auch Sie sich näher mit Entwurfsmustern auseinandersetzen wollen, dann gilt es Folgendes zu beachten, um Missverständnisse von vornherein zu vermeiden:
- Entwurfsmuster sind keine Algorithmen – Algorithmen lösen Probleme (Suchen, Sortieren, etc.) und bieten weniger Flexibilität in der Implementierung.
- Entwurfsmuster sind kein Allheilmittel – Erfindungsreichtum ist bei der Anwendung von Entwurfsmustern immer noch gefragt.
- Entwurfsmuster sind keine Frameworks – Frameworks setzen sich als wiederverwendbarer Code zusammen, Entwurfsmuster enthalten lediglich Beispiele von Code. Frameworks werden für festgelegte Anwendungsbereiche eingesetzt, Entwurfsmuster hingegen können überall eingesetzt werden.
Dieser Abschnitt wurde dem Buch “PHP 5 – Objektorientierte Programmierung” von Matthias Kannengiesser entnommen, das im Franzis Verlag erschienen ist. Sie können es hier direkt bestellen.
Artikel bewerten
(No Ratings Yet)
Loading ...