home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Patterns

Command Pattern

Durch das Command Pattern wird der Aufgerufenene vom Aufrufendem entkoppelt, sie kennen sich nicht mehr.

Damit kann beispielsweise eine Fernbedienung mit einem Hubschrauber, eine Auto und einem Schiff verwendet werden, ohne dass die Fernbedienung geändert werden muss.


Beschreibung des Klassendiagrammes:

Das Interface ICommand schreibt die Methode execute() vor (optional könnte hier auch noch die Methode undo() stehen). Alle konkreten Commands implementieren das ICommand. Ein konkretes Command besitzt eine Instanz des Receivers, in unserem Fall ist das der Heli. Das konkrete Command kann dann, wenn execute() aufgerufen wird, die entsprechende Methode auf dem Heli aufrufen, z.B. fliegeHoch(). Der Caller ist die Fernbedienung, die Fernbedienung besitzt für ihre Knöpfe ICommand, die beim drücken der jeweiligen Taste aufgerufen werden. Der Client bzw Konfigurator, primt die Fernbedienung für den jeweiligen Receiver. Dies muss für jeden neuen Receiver erneut geschehen. Der Konfigurator kennt die konkreten Commands und übergibt sie der Fernbedienung.

Template Pattern

Wenn mehere Klassen bestimmte Funktionalität in einer bestimmten Reihenfolge ausführen müssen und nicht jede Funktionalität selbst implementieren sollen (zwecks Redudanz), dann nehmen wir das Template Pattern.

Beispielsweise, wir besitzen ein Cafe-Haus, auf unserer Speisekarte stehen alle Arten von Kaffee aus aller Welt. Sie werden aber alle in der gleichen Reihenfolge zubereitet nur die Zutaten sind unterschiedlich. Für jeden Kaffee müssen wir Wasser heiß machen, Kaffebohnen übergießen, und Milch hinzufügen. Wasser heiß machen ist für alle gleich, Unterschiede gibt es nur bei den Kaffeebohnen und bei der Milch.

Final Methoden

Final Methoden nehmen wir dann, wenn die Funtionalität nicht von den konkreten Klassen geändert werden darf. Wasser heiß machen soll für alle Kaffees gleich sein.

Abstrakte Methoden

Abstrakte Klassen nehmen wir dann, wenn konkreten Klassen Funktionalität selbst implementieren sollen. Für den Cafe Latte werden andere Bohnen verwendet, als für den südafrikanischen Kaffee.

Hook Methoden

Hook Methoden sind zusätzliche Methoden, wenn wir zwar die Reihenfolge festlegen wollen nicht aber die Funktionalität. Wir haben uns dafür entschlossen nach der Milch hinzufügen Methode noch einen hook anzubieten. Der Italienische Kaffee nutzt die hook Methode um sich selbst noch mit Kaffeepulver zu verzieren.

State Pattern

Wenn wir viele Zustände besitzen, sind die Übergänge zwischen den Zuständen schnell unübersichtlich und im Code schwer wartbar. Wenn wir einen neuen Zustand hinzufügen, müssen wir das jede Methode anpassen.

Die Lösung für das Problem bringt das State Pattern. Zustandsabhängiges Verhalten wir in eine Klasse gekapselt und an die konkreten Zustandsklassen delegiert. Damit erreichen wir, falls wir neue Zustände hnzufügen keine der alten Methoden neu geschrieben werden muss, da die Zustände jetzt unabhängig von einander sind.


Ein State kann entweder als Interface oder als Abstrakte Klasse geschrieben werden. Mit dem Interface machen wir nur die Vorgabe wie die Methoden in den konkreten States heißen sollen, können aber nicht die Implementierung vorgeben. Wenn wir Abstrakte Klasse statt dessen verwenden, können wir für einige Methode die Implementierung vorgeben und für die anderen Methoden die Implementierung offen lassen. Geben wir die Implementierung vor, schreiben wir damit den konkreten States vor, wie die Zustände später aussehen.

Wenn wir statt einem Interface /bzw. abstrakten Klassen die State Klasse statisch machen, hätten alle konkreten States immer den gleichen Zustand. Das State Pattern funktioniert also nicht mit statischen Klassen.

Zustände und deren Übergänge
Klassendiagramm

Proxy Pattern

Der Proxy ist wie ein Türsteher, der seriöse Gäste in die Disco lässt und zwiellichte Kerle draußen stehen lässt. Das Proxy Pattern beschränkt den Zugriff auf Methoden der dahinter liegenden Klasse. Der Proxy kann dabei auch auf entfernte (z.B. Internet) Klassen zugreifen, mittels RMI (oder andere Technologien). Der Rückgabewert einer Methode kann gecachet werden, damit bei einem weiteren Aufruf sofort der gecachete Wert zurück gegeben werden kann, ohne die Methode selbst aufzurufen.

Dynamic Proxy

Bei dem dynamic proxy werden Methodenaufrufe nicht sofort aufgerufen, sondern über die invoke() Methode des InvocationHandlers umgeleitet. In der Kasse InvocationHandler können wir entscheiden ob die Methode aufgerufen werden soll oder nicht. Damit legen wir unterschiedliche Berechtigungen für die Aufrufer der Methode fest. Beispiel: Der Admin darf die Methode aufrufen, der Techniker darf sie nicht aufrufen.

Klassendiagramm des Proxy Patterns

Observer Pattern

Wenn mehrere Objekte über die Änderung eines Subjektes informiert werden sollen. Objekte und Subjekte sollen möglichst lose gekoppelt sein.

Beispiel: eine Wetterstation liefert in unregelmäßigen Abständen die aktuelle Temperatur, die Ausgabe soll au unterschiedlichen Geräten erfolgen, wie PDA, Webseite und SMS. Die Wetterstation ist das Subjekt, PDA, Wetterstation und das Handy mit SMS sind Observer. Es wäre sehr umständlich wenn sich jeder Observer selbst informieren müßte ob aktuelle Daten vorhanden sind und wenn ja sie dann abholen kann. Mit dem Observer Pattern, registrieren sich die einzelnen Observer beim Subjekt. Das Subjekt gibt allen registrierten Oberservern bescheid sobad neue Daten vorhanden sind.

Quelle: http://en.wikipedia.org/wiki/Observer_pattern

Composite Pattern

Mit dem Composite Pattern ist es mögliche Teile und Ganze gleich zu behandeln. Beispiel Dateisystem: Ein Verzeichnis (Ganzes), kann Unterverzeichnisse und Dateien (Teile) besitzen. Ein Unterverzeichnis kann wiederum Verzeichnisse und Dateien besitzen. Durch das Teile und Ganze Prinzip, entsteht eine Baumstruktur.

Quelle: http://en.wikipedia.org/wiki/Composite_pattern

Strategy Pattern

Das Strategy Pattern bietet sich an, wenn austauschbare Varianten eines Algorithmus benötigt werden. Beispielsweise soll die Steuer für unterschiedliche Personen berechnet werden, je nach Einkommen und Steuerklasse müssen andere Steuern gezahlt werden.

Vergleich Strategy Pattern -  State Pattern

Beim State Pattern sind die States selbst dafür zuständig sich zu verwalten, beim Strategy Pattern ist der Aufrufende Context dafür zuständig wann, was wie aufgerufen wird.

 

Quelle: http://en.wikipedia.org/wiki/Strategy_pattern