Software Engineering. 10. Entwurfsmuster II. Franz-Josef Elmer, Universität Basel, HS 2015

Transkript

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

2 Software Engineering: 10. Entwurfsmuster II 2 Die Entwurfsmuster der Gang of Four Die 23 GoF Pattern sind in 3 Gruppen eingeteilt: Erzeugungsmuster: Abstract Factory (87) Builder (97) Factory Method (107) Prototype (117) Singleton (127) Strukturmuster: Adapter (139) Bridge (151) Composite (163) Decorator (175) Facade (185) Flyweight (195) Proxy (207) Verhaltensmuster: Chain of Responsibility (223) Command (233) Interpreter (243) Iterator (257) Mediator (273) Memento (283) Observer (293) State (305) Strategy (315) Template Method (325) Visitor (331)

3 Software Engineering: 10. Entwurfsmuster II 3 Entwurfsmuster: Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. GoF(325) Struktur: AbstractClass +templatemethod() #primitiveoperation1() #primitiveoperation2() primitiveoperation1(); primitiveoperation2(); ConcreteClass #primitiveoperation1() #primitiveoperation2()

4 Software Engineering: 10. Entwurfsmuster II 4 Template Method Beteiligte Klassen: AbstractClass: Implementiert das Grundgerüst eines Verhaltens (z.b. ein Algorithmus) in templatemethod(). Definiert abstrakte Operationen für den variablen Teil des Verhaltens ConcreteClass: Implementiert die variablen Teile des Verhaltens. Zusammenarbeit: ConcreteClass verlässt sich auf AbstractClass welche den invarianten Teil des Verhaltens implementiert. Anwendbar wenn ähnliche Algorithmen implementiert werden sollen, gemeinsames Verhalten von Subklassen in ein Superklasse verschoben werden sollen, um Code-Duplikation zu vermeiden, Erweiterungsmechanismen (hooks) in einem Framework vorgesehen sind.

5 Software Engineering: 10. Entwurfsmuster II 5 Template Method Konsequenzen: Fundamentale Technik der objektorientierten Programmierung. Häufige Verwendung in Frameworks. Beispiel für Inversion of Control auch Hollywoodprinzip genannt ( Don't call us, we'll call you. ). Konform mit den Design Prinzipien DRY Open-Closed Prinzip Liskovsche Substitutionsprinzip Implementierung: Die abstrakten primitiven Operationen sollten als protected deklariert werden, um zu vermeiden, dass sie zweckentfremdet benutzt werden. Die primitiven Operationen können auch konkret sein, wenn klar beschrieben ist, dass sie zum Überschreiben entworfen wurden.

6 Software Engineering: 10. Entwurfsmuster II 6 Template Method Beispiel: Verschiedene Oszillatoren -x: double -v: double -t: double -m: double -gamma: double Oscillator +integrate(timestep:double) #calculateforce(x:double): double -kappa: double HarmonicOscillator +HarmonicOscillator(kappa:double) #calculateforce(x:double): double AnharmonicOscillator -kappa: double -a: double +AnharmonicOscillator(kappa:double,a:double) #calculateforce(x:double): double

7 Software Engineering: 10. Entwurfsmuster II 7 Template Method Klasse Oscillator: public abstract class Oscillator { private double _x, _v, _t, _m, _gamma; protected Oscillator(double m, double gamma) { _m = m; _gamma = gamma; public void integrate(double timestep) { double force = _gamma * _v + calculateforce(_x); protected abstract double calculateforce(double x); Klasse HarmonicOscillator: public class HarmonicOscillator extends Oscillator { private double _kappa; protected HarmonicOscillator(double m, double gamma, double kappa) { super(m, gamma); _kappa = kappa; protected double calculateforce(double x) { return _kappa * x;

8 Software Engineering: 10. Entwurfsmuster II 8 Entwurfsmuster: Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. GoF(315) Struktur: ClientClass methodusingstrategy() -s 1 «Interface» Strategy +operation() s.operation(); ConcreteStrategyA +operation() ConcreteStrategyB +operation()

9 Software Engineering: 10. Entwurfsmuster II 9 Strategy Beteiligte Klassen: Strategy: Definiert ein gemeinsames Interface für alle unterstützten Algorithmen. ConcreteStrategy: Konkrete Implementierung eines Algorithmus. ClientClass: Hält ein Objekt einer Klasse die Strategy implementiert. Zusammenarbeit: Ruft in methodusingstrategy() die Methode des konkreten Strategy Objekts auf. Anwendbar wenn Switch Statements oder if-else-if Ketten vermieden werden sollen, das Verhalten zur Laufzeit geändert werden soll, die Implementierung eines Algorithmus' vor dem Client versteckt werden soll, mehrere Klassen gleichartige Methoden haben, die denselben Kontrakt erfüllen.

10 Software Engineering: 10. Entwurfsmuster II 10 Strategy Konsequenzen: Fundamentale Technik der objektorientierten Programmierung. Wahrscheinlich das am häufigsten benutzte Muster. Ähnlich zu Template Method Pattern: Unterschied: Komposition statt Vererbung Konform mit den Design Prinzipien Open-Closed Prinzip Geheimnisprinzip Komposition vor Vererbung Implementierung: Ursprung des konkreten Strategy Objekts: Argument im Konstruktor von ClientClass Argument in methodusingstrategy() Attribut welches durch die Methode setstrategy() gesetzt werden kann Dem Strategy Objekt können über die Methode Daten als Parameter übergeben werden.

11 Software Engineering: 10. Entwurfsmuster II 11 Strategy Beispiel: Verschiedene Oszillatoren Oscillator -x: double -v: double -t: double -m: double -gamma: double +setforce(force:force) +integrate(timestep:double) 1 «Interface» Force +calculate(double:x):double -kappa: double HarmonicForce +HarmonicForce(kappa:double) +calculate(x:double): double AnharmonicForce -kappa: double -a: double +AnharmonicForce(kappa:double,a:double) +calculate(x:double): double

12 Software Engineering: 10. Entwurfsmuster II 12 Strategy Klasse Oscillator: public class Oscillator { private double _x, _v, _t, _m, _gamma; private Force _force; protected Oscillator(double m, double gamma) { _m = m; _gamma = gamma; public void setforce(force force) { _force = force; public void integrate(double timestep) { double force = _gamma * _v + _force.calculate(_x); Klasse HarmonicForce: public class HarmonicForce implements Force { private double _kappa; protected HarmonicForce(double kappa) { _kappa = kappa; public double calculate(double x) { return _kappa * x;

13 Software Engineering: 10. Entwurfsmuster II 13 Strategy: Beispiel aus Java AWT & Swing LayoutManager: Container +setlayout(lm:layoutmanager) 0..1 «Interface» LayoutManager +layoutcontainer(parent:container) Panel Window JComponent FlowLayout BorderLayout Frame JPanel JFrame

14 Software Engineering: 10. Entwurfsmuster II 14 Vergleich: Template Method vs. Strategy Statisch vs. dynamisch: Template Method: Die primitiveoperation() Methoden sind statisch an eine bestimmte Subklasse gebunden. Strategy: Das Strategy Objekt wird erst zur Laufzeit an die Instanz einer ClientClass gebunden. Es kann auch jederzeit ausgewechselt werden. Kombinierbarkeit, eindimensional vs. mehrdimensional: Template Method: Ein Template (abstrakte Template Klasse) kann mit verschiedenen Implementierungen der 'primitive operations' kombiniert werden. Bei m Templates und n unterschiedlichen Implementierungen 'der primitive operations' braucht es n m Subklassen. Strategy: Bei n Templates und m Strategien braucht es nur n+m konkrete Klassen. Beispiel: Container (Template ClientClass) und LayoutManager (Strategy).

15 Software Engineering: 10. Entwurfsmuster II 15 Entwurfsmuster: Factory Method Define an interface for creating an object, but let subclasses decide which class to instanciate. Factory Method lets a class defer instantiation to subclasses. GoF(107) Struktur: Creator «Interface» Product ConcreteProduct «use» «create» +operation() #create(): Product ConcreteCreator Product p = create(); #create() return new ConcreteProduct();

16 Software Engineering: 10. Entwurfsmuster II 16 Factory Method Beteiligte Klassen: Product: Definiert ein Interface der Objekte, welche durch die Factory Methode erzeugt werden. ConcreteProduct: Eine konkrete Klasse welche das Interface Produkt implementiert. Creator: Deklariert und benutzt die Factory Methode create(). ConcreteCreator: Implementiert die Factory Methode und liefert eine Instanz der Klasse ConcreteProduct. Zusammenarbeit: Der Creator delegiert die Erzeugung an seine Subklasse. Die Creator Klasse kennt nur das Interface Produkt. Anwendbar wenn die Erzeugung eines Objekts nicht hart verdrahtet sein soll, die Creator Klasse offen sein soll gegenüber zukünftigen neuen Klassen, die das Product Interface implementieren.

17 Software Engineering: 10. Entwurfsmuster II 17 Factory Method Konsequenzen: Die Beziehung zwischen Creator und ConcreteCreator ist genau die Beziehung zwischen AbstractClass und ConcreteClass im Template Method Pattern. Im Unterschied zum Template Method Pattern ist hier die abstrakte Methode primitiveoperation() sehr spezifisch: Sie erzeugt ein Objekt. Das Wie der Objekterzeugung ist hinter create() versteckt (Geheimnisprinzip). Implementierung: Der Methode create() können auch Parameter übergeben werden, die direkt als Parameter für den Konstruktor verwendet werden können. Konkrete Implementierungen der create() Methode müssen nicht bei jedem Aufruf eine neue Instanz erzeugen. Es können Instanzen wieder verwendet werden wenn entweder ihr Zustand unveränderlich ist (eng. immutable objects) oder sie in einem Zustand sind, der Wiederverwendung erlaubt (z.b. Datenbankverbindungen).

18 Software Engineering: 10. Entwurfsmuster II 18 Factory Method: Varianten Abstract Factory: Factory via Strategy Pattern ClientClass methodusingfactory() -factory 1 «Interface» Factory +create():product ConcreteFactory +create():product Static Factory Method: Das Erzeugerobjekt ist eine Klasse. Beispiel: Klasse java.awt.font hat folgende statische Methode, welche eine neue Instanz der Klasse erzeugt: public static Font decode(string description) Factories selber werden oft mit statischen Factory Methoden erzeugt.

19 Software Engineering: 10. Entwurfsmuster II 19 Entwurfsmuster: Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. GoF(293) Alternativer Name: Publish-Subscribe Struktur: Subject +attach(o:observer) +deattach(o:observer) #notifyobservers() * «Interface» Observer +update() for each observer do observer.update(); ConcreteSubject ConcreteObserver state = s; notifyobservers(); -state:object +getstate():object +setstate(s:object) 1 +update()

20 Software Engineering: 10. Entwurfsmuster II 20 Observer Beteiligte Klassen: Subject (Publisher): Abstrakte Klasse, welche eine beliebige Zahl von Observer verwaltet. Observer (Subscriber): Interface für Objekte, die an Zustandsänderungen eines ConcreteSubject Objekts interessiert sind. ConcreteSubject: Hält einen Zustand, an dem Observers Interesse haben. ConcreteObserver: Reagiert auf Zustandsänderungen der assoziierten Instanz von ConcreteSubject.

21 Software Engineering: 10. Entwurfsmuster II 21 Observer Zusammenarbeit: :ConcreteSubject c1:concreteobserver setstate(s) notifyobservers() update() c2:concreteobserver getstate() s update() getstate()

22 Software Engineering: 10. Entwurfsmuster II 22 Observer Anwendbar wenn eine Änderung in einem Objekt Änderungen in anderen Objekten nach sich ziehen und diese Objekte erst zur Laufzeit bekannt sind, ein Objekt (Publisher) andere Objekte (Subscribers) benachrichtigen soll, ohne näheres über diese zu wissen, MVC realisiert werden soll, so dass das Model ( Subject) die View- Klassen ( ConcreteObservers) nicht kennt. Konsequenzen: Keine starke Kopplung zwischen Subject und Observer. Z.B. kann ein konkreter Observer aus einer höheren Schicht als das Subject sein, ohne dass das Layer Pattern gestört wird. Im Gegensatz zum normalen Methodenaufruf erlaubt das Observer Pattern die Nachrichtenübermittlung an beliebig viele Empfänger. Gefahr: Komplexes Update Netz wenn ein Update weitere nach sich ziehen: Überflüssige Updates (Performance Problem oder Endlosschleife) Updates in der falschen Reihenfolge

23 Software Engineering: 10. Entwurfsmuster II 23 Observer Implementierung: Der update() Methode kann auch ein Nachrichtenobjekt mitgegeben werden. Dieses kann z.b. die Quelle der Nachricht enthalten, so dass eine Assoziation von dem konkreten Observer auf das Subject Objekt nicht nötig ist. Statt bei jeder Zustandsänderung notifyobservers() aufzurufen, kann auch der Client der Subject-Klasse dies tun. Vorteil: Mehrere direkt aufeinander folgende Änderung werden zu einem Update gebündelt (wichtig für die Performanz bei GUI Applikationen). Nachteil: Das Update wird im Client vergessen. Das ist z.b. verheerend in GUI Applikationen, wenn die Views nicht mehr den Zustand des Models zeigen. Die Obserververwaltung kann in eine eigene Klasse ausgelagert werden (Komposition vor Vererbung), die gemäss dem Strategy Pattern ein Interface (ChangeManager) implementiert, so dass z.b. in notifyobservers() verschiedene Update Strategien realisiert werden können.

24 Software Engineering: 10. Entwurfsmuster II 24 Observer Observer Listener in Java: Namenskonventionen: XXXListener: XXX beliebig mit Grossbuchstabe beginnend. Hat Methoden der Art YYY(XXXEvent event), wobei YYY eine abgeschlossene Tätigkeit beschreibt. addxxxlistener(xxxlistener listener): Ein Listener vom Typ XXXListener wird registriert removexxxlistener(xxxlistener listener): Ein Listener wird aus der Liste der Listeners entfernt fireyyy(xxxevent event): Alle Listeners werden durch den Aufruf der Methode YYY benachrichtigt. Beispiel: ActionListener AbstractButton +addactionlistener(l:actionlistener) +removeactionlistener(l:actionlistener) #fireactionperformed(e:actionevent) * «Interface» ActionListener +actionperformed(e:actionevent) JButton