Verhaltensmuster. Modellieren von komplexem Verhalten

Transkript

1 Verhaltensmuster Modellieren von komplexem Verhalten

2 Verhaltensmuster Modellierung von (komplexem) Verhalten behavioral design patterns Beispiele Beobachter (Observer) Besucher (Visitor) Kommando (Command / Command-Processor) Zustand (State) Iterator

3 Observer Pattern Beobachter Verhaltensmuster Publisher/Subscriber

4 Szenario/Problem Verschiedene Sensoren, Messstationen oder Benutzeroberflächen erkennen/melden veränderte Zustände oder Daten. Die Änderungen sollen den verschiedenen Interessenten bekannt gemacht werden, damit diese bei Bedarf sofort darauf reagieren können. Interessenten können sich an- oder abmelden.

5 Szenario/Problem Die Klimatisierung der Büroräume soll nur falls nötig laufen (zu heiss, zu kalt, zu trocken, zu feucht, tagsüber, wenn jemand da ist, ).

6 Szenario/Problem Verschiedene Kundenberater verkaufen in verschiedenen Filialen Reise-Angebote (Hotel, Flug, Mietauto,.) Die Preise können je nach Buchungsstatus ändern. Jeder Kundenberater soll an seinem Arbeitsplatz immer die aktuellen Angebote, Preise und den Buchungsstatus sehen.

7 Lösung Interessierte Objekte (Klima-Anlage/GUI der Kundenberater) haben die Möglichkeit, sich bei Datenänderungen benachrichtigen zu lassen. Objekte können überwacht werden, so dass jede Zustandsänderung gemeldet (publiziert) wird. Sobald sich ein überwachter Zustand ändert, werden alle angemeldeten Interessenten über diese Änderung informiert.

8 Lösung/Implementation Die Daten werden in einer Observable Klasse (DataObject) verwaltet. Die Interessenten registrieren sich als Observer beim DataObjekt. Bei jeder Daten-Änderung werden die Interessenten informiert (notifyobservers())

9 Lösung/Struktur/Implementation public abstract class Observable{ private Stack<Observer> obs = new Stack<>(); public void addobserver(observer o) { obs.push(o); public void removeobserver(observer obs) { obs.pop(o); public void notifyobservers(object obj) { for(observer o: obs) obs.update(this, obj);

10 Lösung/Struktur/Implementation public class DataObject extends Observable { private Object data1, data2, ; public void setdata1(object o) { data1 = o; // informiere die Observer notifyobservers(data1);...

11 Lösung/Struktur/Implementation public class ConcreteObserver implements Observer { public void update(observable obsv, Object obj) { // auf Daten-Änderung reagieren......

12 Vorteile Die Interessenten passen automatisch den Zustand an, sobald sich ein Objekt ändert. Das DataObjekt muss die Observer nicht kennen. Die Koppelung ist lose (die An- oder Abmeldung ist jederzeit möglich). Es muss nicht bekannt sein, wie viele Interessenten es gibt.

13 Nachteile Die lose Koppelung bewirkt, dass nicht gesteuert werden kann, welcher Observer wann benachrichtigt wird ev. viele unnötige Benachrichtigungen. Gefahr der zirkulären Notifizierung (in komplexen Systemen schwierig zu finden)

14 Varianten Die Benachrichtigung liefert alle (neuen) Daten (push) Die Observer holen sich die neuen Daten (falls nötig selber) (pull) Die Benachrichtigung kann mit Hilfe eines separaten Thread erfolgen, so dass keine Wartezeit entsteht. Event (wie in Java) oder Delegate Konzept (wie in C#)

15 Verweis auf andere Muster Ein verwandtes Muster ist das Model View Controller o View ist der Observer o Model ist das Observable o Controller ist für das Event-Handling zuständig.

16 Command Processor Pattern Befehls Verhaltensmuster

17 Szenario/Problem Eingabe-Befehle (User Events, ) sollen von deren Ausführung entkoppelt werden um - sie zu speichern (Historisierung), - sie zu annullieren (undo/redo), - sie wieder zu verwenden (again), - sie zu parametrisieren, - sie zu filtern, verzögern,.

18 Szenario Aufrufe von Methoden sollen in Befehlsklassen ausgelagert werden. Der Befehl kennt sein Ziel (Model/Supplier) und alle nötigen Parameter Der Command Processor speichert die Command Objekte und koordiniert deren Ausführung. Der Command Processor kann dadurch auch Befehle invertieren (undo), nochmals ausführen (again), loggen, asynchron ausführen, bündeln

19 Lösung/Implementation Befehls-Verursacher (Absender) Befehls-Empfänger

20 Lösung/Implementation

21 Lösung/Struktur/Implementation public interface Command { public void do_it(); public void undo_it(); public class UndoableCommand implements Command { private Object commandparams; public void do_it() { // execute command public void undo_it() { // undo command...

22 Lösung/Struktur/Implementation public interface CommandProcessor { Stack<Command> cmdlist; public void submit(command cmd) { cmdlist.push(cmd): execute(cmd); public void execute() { cmdlist.read().do_it(); public void undocommand() { cmdlist.pop().undo_it();

23 Vorteile Neue Befehle können schnell und einfach hinzugefügt werden. Befehle können ausgetauscht oder erweitert werden. Die Befehlsausführung wird vom Befehl entkoppelt Flexibilität.

24 Nachteile Für jede Art von Befehl wird eine eigene Klasse benötigt. Jeder Befehlsaufruf ergibt ein neues Objekt, welches verwaltet werden muss. Zusätzlicher Aufwand auch beim Aufräumen der alten Befehle.

25 Verweis auf andere Muster Befehls-Makros (Bündelung von Befehlen) können als Kompositum (Stückliste) implementiert werden. Um Objekte in den ursprünglichen Zustand zurückzuführen, kann das Memento-Patten verwendet werden. Speichern des aktuellen internen Objekt- Zustands, um diesen (bei einem undo()) später wieder herzustellen.

26 Visitor Pattern Besucher Verhaltensmuster

27 Szenario/Problem Die Integration verschiedener Hilfs-Operationen (print, normalize, sort, transform, ) in die Klassen einer Objektstruktur ist oft schwierig. Bei Änderungen oder Erweiterungen zum Beispiel um eine neue Funktionalität müssen alle Klassen verändert/erweitert werden. Das Visitor Pattern lagert diese Operationen in externe (Besucher-)Klassen aus. Neue Operationen können dadurch ohne Veränderung der betroffenen Elementklassen definiert werden.

28 Szenario/Problem Visitor Pattern (Besucher Entwurfsmuster) Ein Visitor Objekt kapselt Operationen, welche auf den verschiedenen Elementen einer Objekt- Hierarchie (wie zum Beispiel verschiedenen Dokument-Typen) ausgeführt werden müssen.

29 Anwendung des Pattern Operationen oder Funktionalitäten, welche eine ganze Objekt-Hierarchie (z.b. alle Dokument- Klassen) betreffen, werden mit Vorteil in eine separate Klasse (Visitor) ausgelagert. Dies kann auch für Operationen gelten, welche Informationen aus den Objekten einer Klassenhierarchie sammeln müssen.

30 Lösung/Implementation

31 Lösung/Implementation PrintVisitor / SortVisitor implementiert die visit-funktion des Interface stellt die auszuführende Funktionalität (Dienst) zur Verfügung Document Interface/Basis Klasse deklariert eine Schnittstelle zum Empfang eines Besuchers (accept-methode) Konkretes Element (Order, Bill, Report, ) implementiert die accept Methode

32 Lösung/Struktur/Implementation public interface Visitor { public void visit(order order); public void visit(bill bill); public void visit(report report); public class PrintVisitor implements Visitor { public void visit(order order) { print(order); private void print(order order) { // print the order...

33 Lösung/Struktur/Implementation public interface Visitor { public void visit(order order); public void visit(bill bill); public void visit(report report); public class SortVisitor implements Visitor { public void visit(bill bill) { sort(bill); private void sort(bill order) { // sort the bills...

34 Lösung/Struktur/Implementation public class Order implements Document{ public void accept(visitor visitor) { visitor.visit(this);... public class Bill implements Document{ public void accept(visitor visitor) { visitor.visit(this);...

35 Vorteile Neue Operationen können durch die Definition neuer Visitors einfach hinzugefügt werden. Verwandte Operationen werden im Visitor zentral verwaltet und von besucherfremden Operationen getrennt. Das Visitor Pattern kann für beliebige Klassenhierarchien verwendet werden.

36 Nachteile Für neue konkrete Elemente (z.b. neue Document- Klassen), müssen alle visit-methoden aller Visitors implementiert werden. Die Operationen sind in andere Klassen ausgelagert -> schlechter sichtbar -> komplizierterer Code -> grösserer Aufwand

37 Verwendung Visitor Pattern ist sinnvoll anwendbar wenn viele unterschiedliche, nicht verwandte Operationen auf den Objekten einer Klassen- Hierarchie realisiert werden sollen sich die Klassen der Hierarchie nicht / nur selten ändern auf der Klassen-Hierarchie häufig neue Operationen integriert werden müssen

38 Verweis auf andere Muster Verwante Muster sind Komposit Pattern Gleichbehandlung aller Elemente einer Baumstruktur ( Stückliste) Decorator Pattern Anbieten von Funktionalität auf Klassen ohne Ableitungsstruktur (keine Vererbung). Command Pattern Auslagern der Funktionalität in ein separates Objekt.