Software Engineering. 11. Entwurfsmuster III. Franz-Josef Elmer, Universität Basel, HS 2015

Transkript

1 Software Engineering 11. Entwurfsmuster III Franz-Josef Elmer, Universität Basel, HS 2015

2 Software Engineering: 11. Entwurfsmuster III 2 Entwurfsmuster: Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations. GoF(97) Struktur: Director construct() Builder build() builder.build() ConcreteBuilder build() getresult(): Product 1 Product

3 Software Engineering: 11. Entwurfsmuster III 3 Builder Beteiligte Klassen: Builder: Interface mit diversen Methoden um Teile eines Produktobjektes zu erzeugen. ConcreteBuilder: Implementiert die Buildermethoden. Hält alle Teile, die das Produktobjekt bestimmen. Hat eine Methode, die das fertige Produktobjekt liefert. Director: Eine Klasse mit einer Methode, welche durch den Aufruf von Buildermethoden ein Produktobjekt erzeugt. Product: Klasse, welche das vom ConcreteBuilder zu erzeugende Objekt repräsentiert.

4 Software Engineering: 11. Entwurfsmuster III 4 Builder: Zusammenarbeit :Client «create» :ConcreteBuilder «create» construct() :Director buildpart1() buildpart2() getresult() product

5 Software Engineering: 11. Entwurfsmuster III 5 Builder Anwendbar wenn die Erzeugung eines Objekts ein komplexer Prozess ist der Konstruktionsprozess unterschiedliche Repräsentationen des Produktobjekts ermöglichen soll Konsequenzen: Entkopplung der Konstruktion eines Objektes aus einer Sequenz von möglichen Schritten (definiert durch die Methoden des Builder Interfaces) von der konkreten Erzeugung. Konform mit den Designprinzipien Geheimnisprinzip Open-Closed Prinzip Erlaubt feinere Steuerung der Konstruktion eines Objektes statt eines Konstruktors mit sehr vielen Parametern. Implementierung Das Builder Interface ist nicht nötig, wenn es nur eine Repräsentation des Produktobjektes gibt. Die Builder Methoden geben das Builder Objekt selber zurück und erlauben damit method chaining (ein Charakteristikum von sogenannten fluent APIs).

6 Software Engineering: 11. Entwurfsmuster III 6 Builder: Beispiel in Java API StringBuilder: StringBuilder append(b: boolean): StringBuilder append(n: int): StringBuilder append(c: char): StringBuilder append(s: String): StringBuilder append(o: Object): StringBuilder tostring(): String Example: StringBuilder builder = new StringBuilder(); builder.append("hello ").append(name); String greetings = builder.tostring(); ProcessBuilder: ProcessBuilder command(cmd: String[]): ProcessBuilder redirectoutput(f: File): ProcessBuilder redirecterror(f: File): ProcessBuilder redirectinput(f: File): ProcessBuilder start(): Process Example: ProcessBuilder builder = new ProcessBuilder(); builder.command("data-repository"); builder.command("list", "my-repo").redirecterror(errorfile); Process process = builder.start();

7 Software Engineering: 11. Entwurfsmuster III 7 Entwurfsmuster: Composite Compose objects into a tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. GoF(163) Struktur: Client Component operation() add(c:component) remove(c:component) getchild(index:int) children * Leaf +operation() Composite 0..1 operation() add(c:component) remove(c:component) getchild(index:int) parent for each child do child.operation();

8 Software Engineering: 11. Entwurfsmuster III 8 Composite Beteiligte Klassen: Component: Definiert ein Interface für alle Objekte des Baumes Leaf: Repräsentiert ein Blatt im Baum Composite: Definiert das Verhalten eines Knoten mit Kindern Hält die Kindkomponenten Implementiert alle Operation, die sich auf Kinder beziehen Client: Manipuliert Objekte im Baum via dem Component Interface Zusammenarbeit: Der Client ruft für ein beliebiges Objekt im Baum operation() auf. Abhängig von der Objektklasse bewirkt operation() unterschiedliches. Im Fall eines Composite Objekts wird der Aufruf an alle Kinder weitergereicht. Eventuell werden davor und/oder danach noch zusätzliche Operationen ausgeführt.

9 Software Engineering: 11. Entwurfsmuster III 9 Composite Anwendbar wenn eine baumartige Struktur aus Objekten modelliert werden soll und der Unterschied zwischen Leaf und Composite in gewissen Kontexten ignoriert werden kann. Konsequenzen: Definiert eine Klassenhierarchie aus einfachen Objekten und zusammengesetzten Objekten. Vereinfacht den Client, da einfache und zusammengesetzte Objekt gleich behandelt werden. Ausnahme: Manipulationen der Baumstruktur Es ist einfach neue Objekttypen hinzuzufügen (Open-Closed Prinzip). Nachteil: Manchmal zu Allgemein. Dies kann zu Typenüberprüfung zur Laufzeit führen. Beispiel: Eine neuer Typ hat eine spezielle Methode, die nicht im Component Interface deklariert ist.

10 Software Engineering: 11. Entwurfsmuster III 10 Composite Implementierung: Kindkomponente hat expliziten Zugriff auf Elternkomponente: Component +getparent():composite... oder Component -parent:composite +getparent():composite +setparent(p:composite)... In den Implementierungen der Methoden add() und remove() von Composite muss dies entsprechend berücksichtigt werden. Die Kinder eines Composite-Objekts müssen nicht geordnet sein. Konsequenz: Anderes Zugriffsinterface, z.b. getchildren():component[*] statt getchild(index:int) Maximierung des Component Interfaces durch Hinzufügen von so vielen gemeinsamen Operationen wie möglich. Vorteil: Client muss nicht den Typ der Komponente prüfen Nachteile: Operation machen für gewisse Typen keinen Sinn.

11 Software Engineering: 11. Entwurfsmuster III 11 Composite: Implementierung Deklaration der Methoden des Kinder Managements: im Component Interface: Vorteil: Einheitliches Interface aller Knoten im Baum Nachteile: Überprüfung des Knotentyps für Operationen wie Hinzufügen oder Wegnehmen eines Kindes. Fragwürdige Implementierungen dieser Operationen in den Leaf Klassen. in der Composite Klasse: Vorteil: Kinder Management nur dort wo es Sinn macht. Nachteil: Client Klasse muss bei Manipulationen des Baums auf Composite überprüfen und umwandeln. TreeBuilder TreeUser addleaf(c: Component):TreeBuilder addsubtree():treebuilder Component operation() * Composite children 0..1 operation() add(c:component) remove(c:component) getchild(index:int)

12 Software Engineering: 11. Entwurfsmuster III 12 Composite: Beispiele Java AWT Components: Component paint(g:graphics) getparent():container * Container 0..1 add(c:component) remove(c:component) getcomponentcount():int getcomponent(index:int) W3C XML DOM API: * Node appendchild(c:node):node getchildnodes():nodelist if leaf throw DOMException 0..1 Element setattributenode(a:attr):attr getattributenode(name:string):attr 0..1 * Attr getname():name getvalue():string

13 Software Engineering: 11. Entwurfsmuster III 13 Entwurfsmuster: Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. GoF(257) Struktur: Client Aggregate Iterator createiterator():iterator first():object next():object current():object isdone():boolean ConcreteAggregate createiterator():iterator 1 ConcreteIterator return new ConcreteIterator(this);

14 Software Engineering: 11. Entwurfsmuster III 14 Iterator Beteiligte Klassen: Iterator: Definiert ein Interface für den sequentiellen Zugriff auf die Objekte einer Ansammlung von Objekten (engl.: aggregate, collection). ConcreteIterator: Implementiert das Iterator Interface und hält die momentane Position des Zugriffs (durch current() abfragbar). Aggregator: Definiert ein Interface zur Erzeugung eines Iterator Objekts. ConcreteAggregator: Implementiert das Aggregator Interface und erzeugt eine Instanz einer passenden ConcreteIterator Klasse. Zusammenarbeit: Mit first() holte der Client das erste Objekt. Mit next() wird das jeweils darauf folgende Objekt geholt. Mittels isdone() kann der Client feststellen, ob es noch weiter Objekte gibt oder nicht.

15 Software Engineering: 11. Entwurfsmuster III 15 Iterator Anwendbar wenn auf die Objekte einer Ansammlung zugegriffen werden soll, ohne interne Repräsentation der Ansammlung preiszugeben ein einheitliches Interface zum Zugriff unterschiedlicher Typen von Ansammlungen benötigt wird. Konsequenzen: Konform mit dem Geheimnisprinzip. Unterschiedliche Iterator-Implementierungen erlauben eine Aggregatstruktur auf unterschiedliche Weise zu durchlaufen. Beispiel: Baumstruktur kann entweder zuerst in die Tiefe (deep first) oder in Breite (breadth first) durchlaufen werden. Iterator vereinfacht das Aggregate Interface (nur eine Methode). Mehrere Iteratoren können parallel die Ansammlung durchlaufen. Die Operation zur Erzeugung eines Iterator ist eine Factory Methode. Problem: Was passiert wenn die Aggregatstruktur sich während der Iteration ändert?

16 Software Engineering: 11. Entwurfsmuster III 16 Iterator Implementierung: Statt der vier Operationen des Iterators (first, next, current, isdone) sind auch weniger möglich. Im einfachsten Fall gibt es nur eine Operation next() welche das nächste Objekt oder ein Null-Objekt liefert. Der Traversierungs Algorithmus ist entweder in der konkreten Iterator Klasse implementiert oder in der konkreten Aggregat Klasse. Im letztern Fall speichert der Iterator nur die momentane Position. Ein solcher Iterator wird auch Cursor genannt. In Java sind konkrete Iteratoren oft private innere Klassen der konkreten Aggregatoren.

17 Software Engineering: 11. Entwurfsmuster III 17 Iterator: Beispiele aus der Java API Interface Enumeration: Enumeration Collection API: nextelement():object hasmoreelements():boolean Aggregator Collection Collection iterator():iterator... Java Database Connection (JDBC) API: Aggregator Statement Iterator ResultSet Iterator next():object hasnext():boolean remove() Statement executequery(sql:string):resultset... ResultSet next():boolean getobject(index:int):object...

18 Software Engineering: 11. Entwurfsmuster III 18 Entwurfsmuster: Proxy Provide a surrogate or placeholder for another object to control access to it. GoF(207) Struktur: Client Subject operation() Proxy operation() -realsubject 1 RealSubject operation()... realsubject.operation()...

19 Software Engineering: 11. Entwurfsmuster III 19 Proxy Beteiligte Klassen: Subject: Gemeinsames Interface von RealSubject und Proxy. RealSubject: Definiert reales Objekt welches durch das Proxy Objekt repräsentiert wird. Proxy: Ersatz für das reale Objekt. Delegiert den Methodenaufruf an das reale Objekt weiter. Kontrolliert den Zugriff auf ein reales Objekt. Zusammenarbeit: Aufrufe der im Subject Interface definierten Methoden werden über das Proxy Objekt an das reale Objekt weitergeleitet. Das Proxy Objekt kann davor und/oder danach weitere Aktionen ausführen.

20 Software Engineering: 11. Entwurfsmuster III 20 Proxy Anwendbar wenn das reale Objekt zu Beginn noch nicht zur Verfügung steht das reale Objekt zur Laufzeit gewechselt werden soll, ohne dass der Client etwas davon mitbekommt das reale Objekt vor unberechtigtem Zugriff geschützt werden soll ganz allgemein vor und/oder nach dem Aufruf weitere Operationen nötig sind (z.b. Logging) Aspect Oriented Programming (AOP) Konsequenzen: Konform mit dem Geheimnisprinzip. Proxy Typen: Remote Proxy: Proxy für ein Remote Objekt Virtual Proxy: Proxy als Cache des realen Objekts Protection Proxy: Proxy überprüft Zugriffsberechtigung Copy-on-Write: Statt ein reales Objekt zu kopieren (was viel Zeit und/oder Speicher kosten kann) wird zunächst nur ein Proxy davon erzeugt. Erst wenn die Kopie verändert werden soll, wird das reale Objekt wirklich kopiert.

21 Software Engineering: 11. Entwurfsmuster III 21 Proxy Implementierung: Die Proxy Klasse muss nicht immer die RealSubject Klasse kennen: 1 Subject operation() Proxy operation() RealSubject operation() Ausnahme: Virtual Proxy muss eine Instanz von RealSubject erzeugt. wenn es das erste mal gebraucht wird (lazy initialization). Java Dynamic Proxy (java.lang.reflect.proxy): Erlaubt zur Laufzeit die Erzeugung eines Proxys für ein beliebiges Objekt. Beschränkung: Dieser dynamische Proxy funktioniert nur für Methoden die in einem Interface deklariert sind.

22 Software Engineering: 11. Entwurfsmuster III 22 Entwurfsmuster: Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests and support undoable operations. GoF(233) Struktur: Invoker setcommand(c:command) 1 Command execute() Receiver action() -receiver 1 ConcreteCommand excute() Client receiver.action()

23 Software Engineering: 11. Entwurfsmuster III 23 Command Beteiligte Klassen: Command: Definiert ein Interface für die Ausführung einer Operation. ConcreteCommand: Implementiert execute() durch Aufruf einer korrespondierenden Aktion im gebundenen Receiver Objekt. Receiver: Führt die eigentliche Operation aus. Invoker: Initiiert die Ausführung der Operation via Command Interface. Client: Bindet einen Invoker an einen Receiver via einer ConcreteCommand Instanz. Zusammenarbeit: Client erzeugt ConcreteCommand Objekt zu einem spezifischen Receiver Objekt und übergibt es der Invoker Instanz. Der Invoker ruft die execute() Operation seiner Command Instanz auf, welche den Aufruf an den Receiver weiterleitet.

24 Software Engineering: 11. Entwurfsmuster III 24 Command: Zusammenarbeit :Client :Invoker :Receiver «create» c:concretecommand setcommand() execute() action()

25 Software Engineering: 11. Entwurfsmuster III 25 Command Anwendbar wenn parametrisierbare Aktion benötigt wird die Spezifizierung und Ausführung einer Aktion zu unterschiedlichen Zeiten erfolgen soll ein Undo Mechanismus benötigt wird Command Interface muss um eine undo() Methode erweitert werden und ConcreteCommand muss den alten Zustand speichern. Konsequenzen: Entkopplung zwischen dem Objekt, welches eine Operation einleiten will, und dem Objekt, welches weiss wie die Operation ausgeführt wird. Konform mit den Designprinzipien Geheimnisprinzip Open-Closed Prinzip Unter Einbezug des Composite Patterns können zusammen-gesetzte Kommandos aus einfachen aufgebaut werden.