Die Model View Controller Architektur gehört zu den aufwendigsten und bekanntesten Entwurfsmustern. Dies ist vielleicht auch der Grund warum ich mich lange gescheut habe einen Artikel zu diesem Thema zu verfassen. Ich hoffe daher im Folgenden eine kurze, aber verständliche Beschreibung bieten zu können.
Zudem wird anhand einer sehr simplen Implementation veranschaulicht, wie der Model View Controller funktioniert.

Das Visitor Pattern erlaubt es eine Klasse oder auch eine ganze Objektstruktur um Funktionalitäten zu erweitern ohne diese direkt zu verändern. Die hinzukommende Logik wird im Visitor gekapselt. Die Klasse(n), welche eine Interaktion mit dem Visitor erlauben soll, muss jedoch verändert werden.

Fluent Interfaces (fließende Schnittstellen) haben nichts mit den seit PHP5 bekannten Interfaces zu tun, so viel vorne weg.
Hinter diesem Begriff birgt sich die Möglichkeit aufeinander folgende Methodenaufrufe einer Klasse zu verketten. Dies erspart einerseits redundanten Code (wenn auch minimal) und erhöht zudem die Lesbarkeit. Ermöglicht wird dieses Vorgehen dadurch, indem die Methoden $this, also die eigene Instanz zurückgeben. Dies ist natürlich nur dann möglich, wenn es sich um Methoden handelt, welche sonst keinen Rückgabewert, also void zurückgeben (zum Beispiel Set-Methoden).

Um Methoden nicht fest an eine Klasse zu binden, so dass diese zum Beispiel zur Laufzeit geholt oder ausgetauscht werden können, eignet sich das Command Pattern. Eine Aufgabe wird in einem Objekt gekapselt, um diese als Parameter zu übergeben oder in einer Queue zu registrieren.

Das Decorator Pattern ermöglicht es ein Objekt zur Laufzeit zu erweitern oder dessen Methoden zu verändern. Dadurch erreicht man eine flexiblere Möglichkeit gegenüber statischer Vererbung, indem ein Objekt mit einem oder mehreren Dekorierern versehen wird.

Ein Adapter im mechanischen Sinn dient der Verbindung zweier verschiedener Geräte. Diese Eigenschaft lässt sich auf Schnittstellen in der Programmierung ebenfalls anwenden. Das Adapter Pattern passt die API (Schnittstelle) einer gegebenen Klasse an die davon abweichende Erwartungen einer Implementierung an. Vorkommen könnte dies zum Beispiel beim Aufeinandertreffen zweier Bibliotheken von verschiedenen Autoren.

Ein Observer dient dazu, den Zustand einer Klasse zu überwachen und bestimmte Maßnahmen einzuleiten, falls sich dieser verändert. Im Beispiel geht es darum einen Wert einer Klasse auf das Überschreiten eines Limits hin zu observieren und entsprechende Meldungen auszugeben.

Das Template Method Pattern hat nichts mit Templates im üblichen Sinne zu tun, soviel vorne weg. Es schreibt vielmehr den Ablauf eines Algorithmus vor, ohne dessen einzelne Komponenten zu implementieren. Die Bestandteile werden lediglich bedingt und in ihrer Reihenfolge festgelegt, können jedoch beliebig in den erbenden Klassen umgesetzt werden.

Das Compsosite Pattern (Kompositum - "Zusammengesetztes") ermöglicht es einen Aufruf aus Kommandos verschiedener Klassen zusammenzusetzen. Die Kommandos werden beim Kompositum registriert und bilden zusammen wiederum ein Kommando ab. Dadurch lässt sich eine sehr flexible Schachtelung erreichen.

Das Registry Pattern bietet trotz seiner Einfachheit ein komfortables klassenübergreifendes Daten Handling. Er ermöglicht der Applikation Daten abzulegen um diese an völlig anderer Stelle wieder zu erreichen ohne diese aufwendig "mitzuschleifen".