Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Abteilung für Telekooperation Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster Übung Softwareentwicklung 2 für Wirtschaftsinformatik.

Ähnliche Präsentationen


Präsentation zum Thema: "Abteilung für Telekooperation Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster Übung Softwareentwicklung 2 für Wirtschaftsinformatik."—  Präsentation transkript:

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

2 Abteilung für Telekooperation Entwurfsmuster: Dekorierer / Decorator

3 Abteilung für Telekooperation 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.

4 Abteilung für Telekooperation Entwurfsmuster: Dekorierer / Dekorator VisualComponent draw() TextView Decorator draw() super.draw() drawBorder() aComponent component.draw() ScrollDecorator BorderDecorator scrollPosition borderWidth draw() scrollTo() draw() drawBorder() super.draw() scrollTo() aBorderDecoratoraScrollDecoratoraTextView 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.

5 Abteilung für Telekooperation Entwurfsmuster: Dekorierer / Dekorator aBorderDecoratoraScrollDecoratoraTextView aBorderDecoratoraScrollDecoratoraTextView draw() (super.)draw() component scrollTo() drawBorder()

6 Abteilung für Telekooperation 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.

7 Abteilung für Telekooperation Entwurfsmuster: Besucher / Visitor

8 Abteilung für Telekooperation 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.

9 Abteilung für Telekooperation 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.

10 Abteilung für Telekooperation Entwurfsmuster: Besucher / Visitor Visitor visitConcreteElementA(ConreteElementA) visitConcreteElementB(ConreteElementB) ConcreteVisitor1 v.visitConcreteElementB(this) ConcreteElementA ConcreteElementB accept(v::Visitor) OperationA() accept(v::Visitor) OperationB() v.visitConcreteElementA(this) visitConcreteElementA(concreteElementA) visitConcreteElementB(concreteElementB) ConcreteVisitor2 visitConcreteElementA(concreteElementA) visitConcreteElementB(concreteElementB) ListOfObjects Element accept(v::Visitor)

11 Abteilung für Telekooperation Entwurfsmuster: Besucher / Visitor listOfObjectsaConcreteElementaConcreteVisitor doSomething() accept(v::Visitor) visit(this) operationA() for some elements in listOfObjects

12 Abteilung für Telekooperation Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility

13 Abteilung für Telekooperation 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.

14 Abteilung für Telekooperation 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"

15 Abteilung für Telekooperation Entwurfsmuster: Zuständigkeitskette / Chain of Responsibility ClientHandler handleRequest() canHandle() ConcreteHandler1 handleRequest() canHandle() doSomething() ConcreteHandler2 handleRequest() canHandle() doSomething() successor if(canHandle()) { doSomething() } else { // deligate successor.handleRequest() }

16 Abteilung für Telekooperation 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 –goal: generating an object with well defined interface but of variable dynamic type –solution: analog to Abstract Factory; class let sub-class generate the object Prototype –goal: generating an object with well defined interface but of variable dynamic type –solution: creation of an object as "copy" of a prototype

17 Abteilung für Telekooperation 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

18 Abteilung für Telekooperation 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

19 Abteilung für Telekooperation 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

20 Abteilung für Telekooperation 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


Herunterladen ppt "Abteilung für Telekooperation Entwurfsmuster (Software Design Patterns) Verhaltens-Entwurfsmuster Übung Softwareentwicklung 2 für Wirtschaftsinformatik."

Ähnliche Präsentationen


Google-Anzeigen