Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster

Präsentation zum Thema: "Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster"—  Präsentation transkript:

1 Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster
Übung Softwareentwicklung 2 für Wirtschaftsinformatik Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster Überblick

2 Entwurfsmuster: Dekorierer / Decorator
Überblick

3 Entwurfsmuster: Dekorierer / Dekorator
Problem: Manchmal möchte man zusätzliche Struktur und Verhalten einem Objekt nicht jedoch gleich einer ganzen Klasse (z.B.: durch Vererbung) zuorgnen. Lösung: Die Instanz eines Dekorierers wird vor die zu dekorierende Klasse geschaltet. Der Dekorierer hat die gleiche Schnittstelle wie die zu dekorierende Klasse. Aufrufe an den Dekorierer werden dann verändert oder unverändert weitergeleitet (Delegation), oder sie werden komplett in Eigenregie verarbeitet. Der Dekorierer ist dabei "unsichtbar", da der Aufrufende gar nicht mitbekommt, dass ein Dekorierer vorgeschaltet ist. In einer alternativen Variante kann der Dekorierer als eine Strategie eingebunden und explizit aufgerufen werden. Überblick

4 Entwurfsmuster: Dekorierer / Dekorator
Ein Textfeld soll mit einer Umrahmung "dekoriert" werden. Zwischen den Aufrufer und das Textfeldobjekt wird das entsprechende Dekoriererobjekt eingefügt. Das Dekoriererobjekt erzeugt die Umrahmung, ein weiteres das Scrolling und übergibt den Kontrollfluss an das Textfeld. Da der Dekorierer dieselbe Schnittstelle hat, ändert sich aus der Sicht des Aufrufers nichts. aComponent VisualComponent draw() TextView Decorator draw() component.draw() ScrollDecorator BorderDecorator super.draw() scrollTo() scrollPosition borderWidth draw() scrollTo() draw() drawBorder() super.draw() drawBorder() aBorderDecorator aScrollDecorator aTextView Überblick

5 Entwurfsmuster: Dekorierer / Dekorator
component component aBorderDecorator aScrollDecorator aTextView aBorderDecorator aScrollDecorator aTextView draw() (super.)draw() (super.)draw() scrollTo() drawBorder() Überblick

6 Entwurfsmuster: Dekorierer / Dekorator
Vorteile: Es können mehrere Dekorierer hintereinandergeschaltet werden Die zu dekorierende Klasse ist nicht unbedingt festgelegt (wohl aber deren Schnittstelle) Die Dekorierer können zur Laufzeit und sogar nach der Instantierung ausgetauscht werden Lange, unübersichtliche Vererbungshierarchien werden vermieden. Nachteile: Eventuell müssen viele Methoden implementiert werden, welche die Aufrufe lediglich weiterleiten. Erweiterungen der zu dekorierenden Klasse werden unabsichtlich versteckt. Der Aufbau der Dekorierer-Instanzen wird komplexer. Als Hilfe kann dazu das Entwurfsmuster des Erbauer (Builder) dienen. Überblick

7 Entwurfsmuster: Besucher / Visitor
Überblick

8 Entwurfsmuster: Besucher / Visitor
Problem: Die Integration verschiedener nicht miteinander verwandter Operationen in die Klassen einer Objektstruktur gestaltet sich oft schwierig. Bei der Erweiterung um neue Operationen müssen alle Klassen erweitert werden. Zweck: dient der Kapselung einer auf Elementen einer Objektstruktur auszuführenden Operation. Lösung: Das Besuchermuster lagert die Operationen in externe Besucherklassen. Dazu müssen die zu besuchenden Klassen jedoch eine Schnittstelle zum Empfang eines Besuchers definieren. Vorteil: Definition neuer Operationen ist dadurch ohne Veränderung der betroffenden Elementklassen möglich. Überblick

9 Entwurfsmuster: Besucher / Visitor
Verwendung: Generell empfiehlt sich die Verwendung von Besuchern, wenn: viele unterschiedliche, nicht verwandte Operationen auf einer Objektstruktur realisiert werden sollen, sich die Klassen der Objektstruktur nicht verändern, häufig neue Operationen auf der Objektstruktur integriert werden müssen oder ein Algorithmus über die Klassen einer Objektstrukur verteilt arbeitet, aber zentral verwaltet werden soll. Überblick

10 Entwurfsmuster: Besucher / Visitor
visitConcreteElementA(ConreteElementA) visitConcreteElementB(ConreteElementB) ConcreteVisitor1 ConcreteVisitor2 visitConcreteElementA(concreteElementA) visitConcreteElementB(concreteElementB) visitConcreteElementA(concreteElementA) visitConcreteElementB(concreteElementB) ListOfObjects Element accept(v::Visitor) ConcreteElementA ConcreteElementB accept(v::Visitor) OperationA() accept(v::Visitor) OperationB() v.visitConcreteElementA(this) v.visitConcreteElementB(this) Überblick

11 Entwurfsmuster: Besucher / Visitor
listOfObjects aConcreteElement aConcreteVisitor doSomething() for some elements in listOfObjects accept(v::Visitor) visit(this) operationA() Überblick

12 Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility
Überblick

13 Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility
Problem: Vermeidung der Kopplung des Senders und Empfänger einer Anfrage. Zweck: Trennung von Sender und Empfänger um mehreren Objekten die Möglichkeit zu geben die Anfrage zu beantworten. Weiterleitung der Anfrage an weitere Objekte um ein Objekt zu finden, dass die Anfrage bearbeiten kann. Verwendung: mehr als ein Objekt sind in der Lage eine Anfrage zu beantworten und der Empfänger ist a priori nicht bekannt und soll automatisch bestimmt werden können. senden einer Anfrage an eine Reihe von Objekten ohne das empfangende Objekt explizit zu spezifizieren. Menge der Objekte, die eine Anfrage beantworten können soll zu Laufzeit bestimmt werden. Überblick

14 Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility
Vorteile: Reduzierung der Kopplung Flexibilisierung der Zuteilung von Aufgaben Nachteil: Beantwortung der Anfrage ist nicht garantiert, da ev. sich keiner verantwortlich "fühlt" Überblick

15 Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility
successor Client Handler handleRequest() canHandle() ConcreteHandler1 ConcreteHandler2 handleRequest() canHandle() doSomething() handleRequest() canHandle() doSomething() if(canHandle()) { doSomething() } else { // deligate successor.handleRequest() } Überblick

16 Patterns: Generating patterns
Abstract Factory goal: generating an object with well defined interface but of variable dynamic type solution: object is not created by a constructor but through requesting it from a factory object Factory Method solution: analog to Abstract Factory; class let sub-class generate the object Prototype solution: creation of an object as "copy" of a prototype Überblick

17 Patterns: Structural Patterns
Family goal: clustering of variants solution: abstract class with sub-classes Adapter (Wrapper) goal: make classes fit to a family solution: new family member that redirects messiges to the class Composite goal: composite object that are treated as single entities solution: composite object is part of the family Decorator goal: add new behavior to a class without changing the class or sub-classing solution: message interception Proxy goal: replacement for another object solution: object with same interface replaces the original object, like decorator but adds no new behavior Überblick

18 Patterns: Structural Patterns
Facade goal: access point for a sub-system solution: additional object as mediator between the client and the sub-system Twin goal: modeling multiple inheritance solution: twins coupling objects bidirectional Überblick

19 Patterns: Behavioural Patterns
Iterator goal: iterate through a set of object without knowing the structure of the set solution: iterator hides the set-specific operations Visitor goal: iterate over a homogeneous data structure, but invoking different operations solution: double dispatching - visitor is called back by the visited object Observer goal: object is informed about state changes of observed object solution: observers sub-scribe to observed object and get notified as soon as state changes Strategy goal: changing behaviour solution: changing behaviour realized as class family which is referenced by the invoking object Überblick

20 Patterns: Behavioural Patterns
Message Object goal: message as data package solution: message classes containing the actual message form a family Template Method goal: structure of an algorithm which should contain some variable parts solution: steps of the algorithm as abstract methods which are overridden in the sub-classes Chain of Responsibility goal: passing messages from object to object solution: chainging object of event handlers Überblick