Design Pattern SS 15 Prof. Albert Zündorf

Slides:



Advertisements
Ähnliche Präsentationen
der Universität Oldenburg
Advertisements

der Universität Oldenburg
Harald Köbler Software Design Patterns Prototype.
Java: Dynamische Datentypen
Listen Richard Göbel.
Komponentenbasierter Taschenrechner mit CORBA
Cassey - Common Answer Set Evaluation sYstem Jean Gressmann Benjamin Kaufmann Robert Lenk.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (05 – Elementare Datenstrukturen) Prof. Th. Ottmann.
Informatik II, SS 2008 Algorithmen und Datenstrukturen Vorlesung 6 Prof. Dr. Thomas Ottmann Algorithmen & Datenstrukturen, Institut für Informatik Fakultät.
Praktikum Entwicklung und Einsatz von Geosoftware I - Sitzung 6 Model-View-Controler als Grundlage für Nutzerschnittstellen Sommersemester 2003 Lars Bernard.
Christian Kästner Modellgetriebene Softwareentwicklung Eclipse Modelling Framework.
XDoclet ETIS SS05.
PRJ 2007/1 Stefan Dissmann Motivation Problem: gleiche Datenstrukturen werden für verschiedene Objekte gebraucht: z.B. Listen von Studierenden, Kunden,
PKJ 2005/1 Stefan Dissmann Klassenhierarchie Person Kunde Goldkunde Lieferant Object.
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 4. Methodenentwurf Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse von.
Programmiermethodik SS 07 Prof. Albert Zündorf
Programmiermethodik SS2009 © 2009 Albert Zündorf, University of Kassel 1 Gliederung 1. Einführung 2. Objektdiagramme zur Analyse von Beispielen 3. Methodenentwurf.
3. Klassendiagramme in Java implementieren
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Programmiermethodik SS 09 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339 im Altbau)
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 6. Story Driven Modeling Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Software Engineering I m Vorlesung im Wintersemester 2008/09 m.
Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1 Objektorientierte Vererbung Student erbt von Person: extensional: Menge der Studenten.
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
Objektorientierte Vererbung
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Compilerbau und Reverse Engineering m Vorlesung im Wintersemester.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Software Engineering I m Vorlesung im Wintersemester 2007/08 m.
1 Reverse Engineering WS 07 / 08 A. Zündorf. Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University 2 Organisatorisches.
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Software Engineering I
Model Driven Engineering SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
Model Driven Engineering SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Software Engineering I m Vorlesung im Wintersemester 2010/11 m.
Programmiermethodik SS2009 © 2009 Albert Zündorf, University of Kassel 1 Gliederung 1. Einführung 2. Objektdiagramme zur Analyse von Beispielen 3. Methodenentwurf.
Model Driven Engineering SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
Programmiermethodik SS 10 Prof. Albert Zündorf
Model Driven Engineering SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
Design Pattern SS 10 Prof. Albert Zündorf
Programmiermethodik WS 2013/14 Prof. Albert Zündorf
Programmiermethodik WS 2011/12 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1338)
Entwurfsmuster – Iterator
Software Design Patterns Creational Patterns Structural Patterns Behavioral Patterns –Behavioral Class Patterns Interpreter Template Method Pattern –Behavioral.
Seite 1 Interface - Konzept Ein Interface führt einen neuen Datentyp ein: interface Frau {... } Das Interface enthält Deklarationen ( keine Definitionen.
Sommersemester 2004 Jan Drewnak Entwicklung und Einsatz von Geosoftware I Praktikum Sitzung 6 Sitzung 6: Model-View-Controller als Grundlage.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Software Engineering I m Vorlesung im Sommersemester 2012 m Prof.
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Client Architecture Data Model GUI KI Socket Connection.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests.
Model Driven Engineering SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
PRJ 2007/1 Stefan Dissmann Verkettete datenstruktur: Liste Problem: Liste, die eine beliebige Zahl von Elementen verwaltet Operationen: Erzeugen, Anfügen,
Einführung in die Informatik für Naturwissenschaftler und Ingenieure (alias Einführung in die Programmierung) (Vorlesung) Prof. Dr. Günter Rudolph Fachbereich.
Einführung in die Programmierung Wintersemester 2009/10 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Programmierung Wintersemester 2009/10 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Informatik für Naturwissenschaftler und Ingenieure (alias Einführung in die Programmierung) (Vorlesung) Prof. Dr. Günter Rudolph Fakultät.
Projektmanagement Ziel und Umfang eines Softwareprojektes definieren
Mag. Thomas Hilpold, Universität Linz, Institut für Wirtschaftsinformatik – Software Engineering 1 Programmierpraktikum Java SS 2005 Mag.Thomas Hilpold.
Software Design Patterns
Java-Kurs - 4. Übung Hausaufgabe Weitere Kontrollstrukturen
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Benutzerdefinierte Tags
IT2 – WS 2005/20061Nov 14, 2005 Visibility  public: Sichtbar in allen Paketen  protected: Sichtbar innerhalb des Pakets und in den Unterklassen  (default,
-LABORPRAKTIKUM- SOMMERSEMESTER 2005
Case Tools Unterstützung für Design Pattern von Vladislav Krasnyanskiy.
Objektorientierte (OO) Programmierung
Systemanalyse BA Heidenheim 2002.
Programmiermethodik WS 2018/19 Prof. Albert Zündorf
Test Summary: ein Fehler pro Tag Test First
 Präsentation transkript:

Design Pattern SS 15 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee 73 34121 Kassel (Raum 1339)

Organisatorisches Umfang: 4 SWS teils Vorlesungen teils Übungen Übungsbetreuung: Marcel Hahn, … Ort und Zeit: Vorlesung: Dienstags 16:00 - 19:00 Raum 1332 (Erste Vorlesung: 14.04.15) Übung:? In obigem Zeitraum Prüfung: Pflichtübungsaufgaben (korrigiert, bepunktet) Folienskript / Screen Videos: http://www.se.eecs.uni-kassel.de. Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Literatur Elementar: Norbisrath, Zündorf, Jubeh: Story Driven Modeling, Amazon 2014, ISBN 9781483949253 (Das Buch überhaupt ) Grundlegend: E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns (Elements of Reusable Object-Oriented Software); Addison Wesley, Bonn, ISBN 0-201-63361-2 (1994) Patterns Home Page: st-www.cs.uiuc.edu/users/patterns/patterns.html Unified Modeling Language: Martin Hitz, Gerti Kappel: UML @ Work, dpunkt.verlag (ziemlich gut) Hintergrund: Frederick P.\ Brooks: The Mythical Man Month, Addison Wesley 1975 (ist nur kurz aber ziemlich witzig, unbedingt mal lesen) Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Gliederung Einführung Design Grundprinzipien Grundlegende Pattern Weitere Pattern Zusammenfassung Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

1. Einführung Ziele der Veranstaltung: Design Know How für große Programme > 100 000 LOC Grundprinzipien der Wartbarkeit und Erweiterbarkeit sicherer Umgang mit Vererbung und Delegation Grundkenntnis der wichtigsten Design Pattern Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beispiel Composite Pattern Realisierung hierarchischer Datenstrukturen kommt in praktisch allen Software-Anwendungen vor naiver Ansatz verursacht dramatische Wartungsprobleme Gute Lösung ist Ausgangspunkt für viele weitere Pattern Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Gliederung Einführung Design Grundprinzipien Grundlegende Pattern Weitere Pattern Zusammenfassung Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

2. Design Grundprinzipien Wartbarkeit Erweiterbarkeit ein Ort eine Design Entscheidung / eine Funktionalität  lokale Änderungen nur lokale Auswirkungen lokaler Änderung (Module/Klassen, Interfaces, Sichtbarkeiten) "wenig" Vererbung Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Vererbung Substitutionsprinzip: Kinder müssen halten was die Eltern versprechen anstelle eines Elternklassenobjektes kann man auch immer ein Unterklassenobjekt verwenden has Employee work (t : Task) : Product Enterprise created does Task Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation Project Presentation Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation has Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation has Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation has Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation has Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Co- und Contravariante Redefinitionen: wegen Substituierbarkeit: input Parameter (Lesen) in Unterklassen nur verallgemeinern (Contravariante Redefinition) output Parametern (Schreiben in Unterklassen) nur spezialisieren (Covariante Redefinition) Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Delegation: alarmDevice :FlashLight … this.alarm(); … :House :Sirene run () alarm () FlashLight alarm() Sirene alarm() MailAlarm alarm() Struktur Verhalten Daten :FlashLight … this.alarm(); … :House :Sirene :MailAlarm Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 1: deliveryBoy :CarBoy :CourierService :BikeBoy :RollerBoy deliver(package, address) DeliveryBoy deliver(pack, addr) deliver(pack, addr) CarBoy BikeBoy deliver(pack, addr) RollerBoy deliver(pack, addr) Struktur Verhalten Daten :CarBoy … myCourier.deliver(p1, "WilliAllee73"); … :CourierService :BikeBoy :RollerBoy Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 1: Implementiert obiges Klassendiagramm zur Delegation (z.B. mit SDMLib) Implementiert die deliver(pack, addr) Methoden der DeliveryBoy–Unterklassen macht jeweils unterschiedliche System.out Ausgaben Schreibt ein Testprogramm dass: ein CourierService Objekt und ein Paket Kaffebohnen erzeugt, nacheinander verschiedene DeliveryBoy Objekte einbaut jeweils deliver(coffeeBeans, "WilliAlle73") aufruft Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Abgabe: Bis Eclipse Projekt "DPH01<matrnr>" Eclipse Projekte inklusive Quellcode JUnit Test start mit einem Click Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Vererbungskonzepte Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Gliederung Einführung Design Grundprinzipien Grundlegende Pattern Weitere Pattern Zusammenfassung Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

1. Referenzarchitektur interaktive System QVT (Control) Generators / Interpreters GUI (Commands) Data Model GUI (Unparsing) Import/ Export Repository Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Datenmodell mit Composite Pattern: naiv Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Datenmodell mit Composite Pattern: besser Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Datenmodell mit Composite Pattern: gut Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 2: Ein Book besteht aus: Parts Chapters Sections Paragraphs Sentences Implementiert ein Datenmodell für Books mit dem Composite Pattern Lest die Kapitelstruktur des Buches ein. zählt die Anzahl der Objekte in euerer Composite Struktur macht euch für weitere Anforderungen bereit Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Composite Pattern Problem: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Naiver Ansatz: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Visitor Pattern rekursiver Durchlauf durch Composite Struktur durchreichen eines Visitor Objekts uniformerer Umgang mit Rekursionsparametern Trennung von Durchlauf und Aktion Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Visitor Pattern Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Visitor Pattern mit Reflection Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Visitor Pattern Zusammenfassung Ziemlich viele accept und visit Methoden Double Dispatch möglich Seperation of concern Zustandsobjekt in der Rekursion Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 3: Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Strategy Pattern ersetze if-then-else-if Ketten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

If-then-else-if Kette: Player main () doMove() mode : int Struktur Verhalten Daten public void doMove () { if (mode == AGGRESSIVE) { …} else if (mode == DEFEND) { …} else if (mode == PLAN) { …} … Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Strategy Pattern: strategy 0..1 :Player :AttackStrat class Player{ main() doMove () MoveStrategy doMove() strategy 0..1 AttackStrat doMove() DefensiveStrat doMove() AStarStrat doMove() Struktur Verhalten Daten :Player :AttackStrat class Player{ public void doMove () { strategy.doMove (); } … :DefensiveStrat :AStarStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Strategy Pattern Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hook Pattern (nicht im Gof-Buch) zusätzliches Verhalten nachträglich einbauen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hook Pattern: strategies n Player main() doMove () StrategyPart doMove() strategies n AttackStrat doMove() DefensiveStrat doMove() ResearchStrat doMove() Struktur Verhalten Daten public void doMove() { produceFood(); for (strat in strategies) { strat.doMove(); } } :Player :AttackStrat :DefensiveStrat : ResearchStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Chain of Responsibility im wesentlichen Hook aber Abbruch wenn erfolgreich bearbeitet Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Chain of Responsibility, original < next Player main() doMove () StrategyPart doMove() next 1 AttackStrat doMove() DefensiveStrat doMove() ResearchStrat doMove() Struktur Verhalten Daten class Player{ public boolean doMove () { if (next != null) { return next.doMove(); } return false; } } :Player :AttackStrat :DefensiveStrat : ResearchStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Chain of Responsibility, original : next Player main() doMove () StrategyPart doMove() next 1 AttackStrat doMove() DefensiveStrat doMove() ResearchStrat doMove() Struktur Verhalten Daten class AttackStrat{ public boolean doMove () { // try it if (canAttack ()) { doAttack (); return true; } else { super.ring (); } } } :Player :AttackStrat :DefensiveStrat : ResearchStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Chain of Responsibility, besser debugbar: Player main() doMove () StrategyPart doMove() handlers {ordered} n AttackStrat doMove() DefensiveStrat doMove() ResearchStrat doMove() Struktur Verhalten Daten class Player{ public boolean doMove () { boolean success = false; for (h in handlers) { success = h.doMove(); if (success) return true; } return false; } } handlers[1] :Player :AttackStrat handlers[2] :DefensiveStrat handlers[3] : ResearchStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Chain of Responsibility, besser debugbar: Player main() doMove () StrategyPart doMove() handlers {ordered} n AttackStrat doMove() DefensiveStrat doMove() ResearchStrat doMove() Struktur Verhalten Daten class AttackStrat { public boolean doMove() { // try it if (canAttack ()) { doAttack (); return true; } else { return false; } } } handlers[1] :Player :AttackStrat handlers[2] :DefensiveStrat handlers[3] : ResearchStrat Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beobachtungen typische Kombinationen von Assoc und Vererbung Unterklassen haben KEINE neue Methoden Unterklassen redefinieren geerbte Methoden Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Beobachtungen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 4: Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

State im wesentlichen Strategy aber systematische Strategy-Änderung nach Benutzung meist Implementierung von Statecharts Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

State: red yellow green timerTick() / car.stop() TraficLight state :Integer timerTick() Car timerTick() / car.setPos(…) car yellow timerTick() / car.stop() green Struktur Verhalten Daten class TrafficLigth { void timerTick() { if (state == RED) { car.setPos (…); state = GREEN; } else if (state == GREEN) { car.stop(); state == YELLOW; } else if (state == YELLOW) car.stop() state = RED; } } } Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

State: Red TraficLight timerTick() Car current car Yellow TLState name states Green Struktur Verhalten Daten class Red { void timerTick() { owner.current = owner.states["green"]; car.setPos(…); } } class Green { void timerTick() { owner.current = owner.states["yellow"]; car.stop(); } } :Car :Red car states["red"] states["yellow"] :Yellow :TrafficLight :Green states["green"] Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Listener/Observer/Model-View-Controler/Mediator im wesentlichen Hook aber Einsatz zur Überwachung von Änderungen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Listener/Observer/Model-View-Controler File size :Integer write(bytes[]) Listener/Observer/Model-View-Controler listeners n Listener propertyChange (obj, attrName, oldVal, newVal) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) Struktur Verhalten Daten class File { void write (bytes[]) { … this.setSize (size+bytes.length()); } void setSize (newVal) { if (this.size != newVal) { int oldVal = size; size = newVal; firePropertyChange ("size", oldVal, newVal); } } … :File size = 23 write ("aaaa") :Drive usedSpace = 38 :File size = 15 Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Listener/Observer/Model-View-Controler File size :Integer write(bytes[]) Listener/Observer/Model-View-Controler listeners n Listener propertyChange (obj, attrName, oldVal, newVal) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) Struktur Verhalten Daten class File { … void firePropertyChange (attrName, oldVal, newVal){ for (l in listeners) { l.propertyChange (this,attrName,oldVal,newVal); } } … :File size = 23 write ("aaaa") :Drive usedSpace = 38 :File size = 15 Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Listener/Observer/Model-View-Controler File size :Integer write(bytes[]) Listener/Observer/Model-View-Controler listeners n Listener propertyChange (obj, attrName, oldVal, newVal) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) Struktur Verhalten Daten class Drive { … void propertyChange (obj,attrName,oldVal,newVal){ usedSpace += newVal – oldVal; } … } :File size = 23 write ("aaaa") :Drive usedSpace = 38 :File size = 15 Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

MVC :SpaceUpdater Drive File Computer usedSpace :Integer size :Integer write(bytes[]) MVC Computer n targets listeners n Listener propertyChange (obj, attrName, oldVal, newVal) SpaceUpdater propertyChange (obj, attrName, oldVal, newVal) Struktur Verhalten Daten class SpaceUpdater { … void propertyChange (obj,attrName,oldVal,newVal){ for (t : targets) { t.usedSpace += newVal – oldVal; } } … :File size = 23 write ("aaaa") :SpaceUpdater :File size = 15 :Drive usedSpace = 38 Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

while (parent != null) { parent.usedSpace += newVal – oldVal; File size :Integer write(bytes[]) Dir usedSpace :Integer Drive n parent files 1 Computer listeners n Listener propertyChange (obj, attrName, oldVal, newVal) SpaceUpdater propertyChange (obj, attrName, oldVal, newVal) Struktur Verhalten Daten :Drive usedSpace = 38 :Computer usedSpace = 38 class SpaceUpdater { … void propertyChange (obj,attrName,oldVal,newVal) { Dir parent = obj.getParent(); while (parent != null) { parent.usedSpace += newVal – oldVal; parent = parent.getParent(); } } … :Dir usedSpace = 38 :Dir usedSpace = 38 :SpaceUpdater write ("aaaa") :File size = 15 :File size = 23 Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe 5?: Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Template Method Motivation ähnlich wie Hook aber feste Vorgabe von abstrakten Template-Methoden alle Template-Methoden müssen überschrieben werden Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Template Method: :FlashLight Alarm + ring () ~ start () ~ stop () FlashLight Sirene ring () MailAlarm ring () ~ start () ~ stop () ~ start () ~ stop () ~ start () ~ stop () Struktur Verhalten Daten :FlashLight class Alarm { void ring () { start (); … stop (); … } } :Sirene :MailAlarm Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Template Method: :FlashLight Alarm + ring () ~ start () ~ stop () FlashLight Sirene ring () MailAlarm ring () ~ start () ~ stop () ~ start () ~ stop () ~ start () ~ stop () Struktur Verhalten Daten :FlashLight class FlashLigth { void start () { powerOn (); } void stop () { powerOff () } } :Sirene :MailAlarm Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Decorator ähnlich wie Composite mit nur einem Kind ähnlich wie Chain-of-Responsibility erweitere eine Strategy um zusätzliche Aktionen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Decorator: alarm 0..1 :House run () ring () Alarm ring () 0..1 orig alarm 0..1 FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten :House class MailAlarm { ring () { sendMail(); orig.ring(); } } :Sirene :MailAlarm Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Proxy ähnlich wie Decorator aber kein Zusatzeffekt sondern remote, lazy oder cache Effekte Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Proxy: :House :Sirene :MailAlarm Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Adapter ähnlich wie Decorator aber Schnittstellenanpassung Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Adapter: :House :Sirene :MailAlarm Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe: Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Flyweight Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Flyweight Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Interpreter / Macro / Command Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Command Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe: Command Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Factory Method: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Prototype: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Komplexer Prototyp Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Abstract Factory: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Hausaufgabe: Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Facade: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Facade: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Plugins: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Import Umkehrung: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Import Umkehrung: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Daten Plugin: Struktur Verhalten Daten Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Reuse Architekturen: Bibliotheken Frameworks Plugin Architekturen Software Bus / ECMA Toaster Corba / RMI / REST Component & Connector Android Intents Product Line Architecture Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Components & Connectors Architekturen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Components & Connectors Architekturen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Components & Connectors Architekturen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Components & Connectors Architekturen Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Wie erreicht man: Wartbarkeit Erweiterbarkeit Qualität Produktivität Sicherheit Robustheit Usability Skalierbarkeit Verfügbarkeit Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel

Design Pattern SS2015 © 2015 Albert Zündorf, University of Kassel