design pattern ss 10 prof. albert zündorf fachgebiet für software engineering wilhelmshöher allee...
TRANSCRIPT
Design Pattern SS 10
Prof. Albert Zündorf
Fachgebiet für Software EngineeringWilhelmshöher Allee 73
34121 Kassel(Raum 1339)
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 2
Organisatorisches
Umfang: 4 SWS teils Vorlesungen teils Übungen
Übungsbetreuung: Johannes Spohr, Sebastian Schulz
Ort und Zeit: Vorlesung: Dienstags 16:00 - 19:00 Raum 2104
(Erste Vorlesung: 13.04.10)Übung:? In obigem Zeitraum
Prüfung: Pflichtübungsaufgaben (korrigiert, bepunktet)
Folienskript / Screen Videos: http://www.se.eecs.uni-kassel.de.
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 3
Literatur
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 SS2010 © 2010 Albert Zündorf, University of Kassel 4
Gliederung
1. Einführung
2. Design Grundprinzipien
3. Grundlegende Pattern
4. Weitere Pattern
5. Zusammenfassung
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 5
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
neue UML 2.0 features
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 6
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 SS2010 © 2010 Albert Zündorf, University of Kassel 7
Gliederung
1. Einführung
2. Design Grundprinzipien
3. Grundlegende Pattern
4. Weitere Pattern
5. Zusammenfassung
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 8
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 SS2010 © 2010 Albert Zündorf, University of Kassel 9
Vererbung
Substitutionsprinzip:Söhne müssen halten was die Väter versprechen
anstelle eines Vaterklassenobjektes kann man auch immer ein Unterklassenobjekt verwenden
EnterpriseEmployee
work (t : Task) : Product
Manager
work (t : Task) : Productmanage ( proj : Project ) : Presentation
hat
Project
Task
Presentation
Product
createddoes
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 10
Beispielsituationen
EnterpriseEmployee
work (t : Task) : Product
Manager
work (t : Task) : Productmanage ( proj : Project ) : Presentation
hat
Project
Task
Presentation
Product
createddoes
…prod = e.work (t);…
Struktur
Verhalten Daten :Employee
:Employee
:Manager
:Task
:Product
:Presentation :Project
:Task
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 11
Beispielsituationen
EnterpriseEmployee
work (t : Task) : Product
Manager
work (t : Task) : Productmanage ( proj : Project ) : Presentation
hat
Project
Task
Presentation
Product
createddoes
…prod = e.work (t);…
Struktur
Verhalten Daten :Employee
:Employee
:Manager
:Task
:Product
:Presentation :Project
:Task
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 12
Beispielsituationen
EnterpriseEmployee
work (t : Task) : Product
Manager
work (t : Task) : Productmanage ( proj : Project ) : Presentation
hat
Project
Task
Presentation
Product
createddoes
…prod = e.work (t);…
Struktur
Verhalten Daten :Employee
:Employee
:Manager
:Task
:Product
:Presentation :Project
:Task
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 13
Beispielsituationen
EnterpriseEmployee
work (t : Task) : Product
Manager
work (t : Task) : Productmanage ( proj : Project ) : Presentation
hat
Project
Task
Presentation
Product
createddoes
…prod = e.work (t);…
Struktur
Verhalten Daten :Employee
:Employee
:Manager
:Task
:Product
:Presentation :Project
:Task
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 14
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 SS2010 © 2010 Albert Zündorf, University of Kassel 15
Delegation:
House
run ()alarm ()
FlashLight
alarm()
Sirene
alarm()MailAlarm
alarm()
alarmDevice
Struktur
Verhalten Daten
…this.alarm();… :House
:FlashLight
:Sirene
:MailAlarm
AlarmDevice
alarm ()
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 16
Hausaufgabe 1:
Implementiert das Klassendiagramm zur Delegation
Implementiert die alarm () Methoden der AlarmDevice -Unterklassen mit unterschiedlichen System.out Ausgaben
Schreibt ein Testprogramm dass: ein House erzeugt, das House nacheinander mit verschieden AlarmDevice
verbindet jeweils einen alarm() auslöst
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 17
Abgabe:
Bis
Eclipse Workspace mit Projekt mit JUnit Test
start mit einem Click
Eclipse Projekte inklusive Quellcode
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 18
Gliederung
1. Einführung
2. Design Grundprinzipien
3. Grundlegende Pattern
4. Weitere Pattern
5. Zusammenfassung
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 19
1. Referenzarchitektur interaktive System
Repository
Data Model
GUI(Commands)
Generators / Interpreters
QVT(Control)
Import/ Export
GUI(Unparsing)
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 20
Datenmodell mit Composite Pattern: naiv
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 21
Datenmodell mit Composite Pattern: besser
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 22
Datenmodell mit Composite Pattern: gut
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 23
Hausaufgabe 2:
Implementiert ein Datenmodell für ein Filesystem mit dem Composite Pattern
Lest eine Teilbaum eueres Computers ein
es sollte eine Jar Datei enthalten sein.
zählt die Anzahl der Files inklusive der Files in den Jar Dateien
summiert die Dateigrößen aller .java Dateien auf
macht euch für weitere Anforderungen bereit
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 24
Composite Pattern Problem:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 25
Naiver Ansatz:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 26
Visitor Pattern
rekursiver Durchlauf durch Composite Struktur
durchreichen eines Visitor Objekts
uniformerer Umgang mit Rekursionsparametern
Trennung von Durchlauf und Aktion
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 27
Visitor Pattern
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 28
Visitor Pattern
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 29
Visitor Pattern
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 30
Visitor Pattern Zusammenfassung
Ziemlich viele accept und visit Methoden
Double Dispatch möglich
Seperation of concern
Zustandsobjekt in der Rekursion
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 31
Hausaufgabe 3:
stellt das Composite Pattern für Files vom letzten Mal auf ein Visitor pattern um.
Baut einen Visitor zur Summierung der Dateigrößen aller .java Dateien auf
Baut einen Visitor der alle Dateien zählt, auf deren Namen ein mitgelieferter regulärer Ausdruck matcht
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 32
Strategy Pattern
ersetze if-then-else-if Ketten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 33
If-then-else-if Kette:
Struktur
Verhalten Datenpublic void ring () {
if (mode == SIRENE){ …}else if (mode == FLASH){ …}else if (mode == MAIL){ …}…
House
run ()ring ()
mode : int
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 34
MailAlarm
ring ()
Strategy Pattern:
House
run ()ring ()
Alarm
ring ()
Sirene
ring ()
alarm 0..1
Struktur
Verhalten Daten
class House {
public void ring (){
alarm.ring ();}
…
:House :FlashLight
:Sirene
:MailAlarm
FlashLight
ring ()
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 35
Strategy Pattern
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 36
Hook Pattern (nicht im Gof-Buch)
zusätzliches Verhalten nachträglich einbauen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 37
Hook Pattern:
House
run ()ring ()
Alarm
ring ()
FlashLight
ring ()
Sirene
ring ()MailAlarm
ring ()
externAlarms
Struktur
Verhalten Daten
public void ring (){
storeProtocol ();
for (alarm in externAlarms){
alarm.ring ();}
}
:House :FlashLight
:Sirene
:MailAlarm
n
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 38
Chain of Responsibility
im wesentlichen Hook
aber Abbruch wenn erfolgreich bearbeitet
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 39
< next
Chain of Responsibility, original
House
run ()ring ()
Alarm
ring ()
FlashLight
ring ()
Sirene
ring ()MailAlarm
ring ()
alarm
Struktur
Verhalten Daten
class Alarm {public boolean ring () {
if (next != null){
return next.ring();}return false;
}}
:House :FlashLight
:Sirene
:MailAlarm
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 40
Chain of Responsibility, original :
House
run ()ring ()
Alarm
ring ()
FlashLight
ring ()
Sirene
ring ()MailAlarm
ring ()
alarm
Struktur
Verhalten Datenclass FlashLight {
public boolean ring () {// try itif (bulb.isReady ()) {
bulb.activate ();return true;
}else {
super.ring ();} } }
:House :FlashLight
:Sirene
:MailAlarm
< next
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 41
Chain of Responsibility, besser debugbar:
House
run ()ring ()
Alarm
ring ()
FlashLight
ring ()
Sirene
ring ()MailAlarm
ring ()
alarms n
Struktur
Verhalten Datenclass House {
public boolean ring () {boolean success = false;for (a in alarms) {
success = a.ring();if (success)
return true;}return false;
} }
:House :FlashLight
:Sirene
:MailAlarm
{ordered}
alarms[1]
alarms[2]
alarms[3]
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 42
Chain of Responsibility, besser debugbar:
Struktur
Verhalten Datenclass FlashLight {
public boolean ring () {// try itif (bulb.isReady ()) {
bulb.activate ();return true;
}else {
return false;} } }
:House :FlashLight
:Sirene
:MailAlarm
House
run ()ring ()
Alarm
ring ()
FlashLight
ring ()
Sirene
ring ()MailAlarm
ring ()
alarms n{ordered}
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 43
Beobachtungen
typische Kombinationen von Assoc und Vererbung
Unterklassen haben KEINE neue Methoden
Unterklassen redefinieren geerbte Methoden
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 44
Beobachtungen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 45
Hausaufgabe 4:
Baut euer Hausbeispiel aus der ersten Hausaufgabe in eine Chain of Responsibility um.
Sinnvolle Tests
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 46
State
im wesentlichen Strategy
aber systematische Strategy-Änderung nach Benutzung
meist Implementierung von Statecharts
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 47
State:
Struktur
Verhalten Daten
TraficLight
state :Integer
transferCar(car)
Car
class TrafficLigth {void transferCar (Car car) {
if (state == GREEN) {car.setPos (…);state = YELLOW;
}else if (state == YELLOW) {
car.stop();state == RED; }
else if (state == RED)car.stop()state = GREEN;
} } }
green
yellow
red
transferCar(car) / car.setPos(…)
transferCar(car) / car.stop()
transferCar(car) / car.stop()
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 48
State:
Struktur
Verhalten Daten
TLState
Green
Yellow
Red
currentTraficLight
transferCar(car)
Car
:TrafficLight
:Car
:Red
:Yellow
:Green
namestates
states["red"]
states["yellow"]
states["green"]
class Red {void transferCar (Car car) {
car.stop()owner.current = owner.states["green"];
} }
class Green {void transferCar (Car car) {
car.setPos(…)owner.current = owner.states["yellow"];
} }
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 49
Listener/Observer/Model-View-Controler/Mediator
im wesentlichen Hook
aber Einsatz zur Überwachung von Änderungen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 50
Listener/Observer/Model-View-Controler
Struktur
Verhalten Daten
Drive
usedSpace :Integer
propertyChange (obj, attrName, oldVal, newVal)
File
size :Integer
write(bytes[])
:Drive
usedSpace = 112
write ("aaaa")
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
:File
size = 42
listeners >
n
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 51
Listener/Observer/Model-View-Controler
Struktur
Verhalten Daten
Drive
usedSpace :Integer
propertyChange (obj, attrName, oldVal, newVal)
File
size :Integer
write(bytes[])
:Drive
usedSpace = 112
write ("aaaa")
class File {…void firePropertyChange (attrName, oldVal, newVal){
for (l in listeners){
l.propertyChange (this,attrName,oldVal,newVal);
} }…
:File
size = 23
:File
size = 42
listeners >
n
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 52
Listener/Observer/Model-View-Controler
Struktur
Verhalten Daten
Drive
usedSpace :Integer
propertyChange (obj, attrName, oldVal, newVal)
File
size :Integer
write(bytes[])
:Drive
usedSpace = 112
write ("aaaa")
class Drive {…void propertyChange (obj,attrName,oldVal,newVal){
usedSpace += newVal – oldVal;} }…
:File
size = 23
:File
size = 42
listeners >
n
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 53
Listener/Observer/Model-View-Controler
Struktur
Verhalten Daten
Drive
usedSpace :IntegerFile
size :Integer
write(bytes[])
:Drive
usedSpace = 112
write ("aaaa")
class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal){
for (t : targets) {t.usedSpace += newVal – oldVal;
} } }…
:File
size = 23
:File
size = 42
listeners >
n
SpaceUpdater
propertyChange (obj,attrName,oldVal,newVal)
targets >n
:SpaceUpdater
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 54
Model-View-Controler/Mediator
Struktur
Verhalten Daten
Drive
usedSpace :IntegerFile
size :Integer
write(bytes[])
:Drive
usedSpace = 112
write ("aaaa")class SpaceUpdater {…void propertyChange (obj,attrName,oldVal,newVal){
for (t : targets) {t.usedSpace += newVal – oldVal;
} } }…
:File
size = 23
:File
size = 42
listeners >
n
SpaceUpdater
propertyChange (obj,attrName,oldVal,newVal)
targets >n
:SpaceUpdater
:Computer
usedSpace = 1012
Computer
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 55
Hausaufgabe 5?:
Baut ein GUI für ein Auto
es soll nur die Geschwindigkeit modelliert werden
die Geschwindigkeit soll auf zwei Wegen visualisiert werden: Zahldarstellung (JSpinner) Schieberegler
die Geschwindigkeit soll in beiden Views editiert werden können und von einem Testprogramm verstellt werden
macht eine Tabelle für mehrere Autos
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 56
Listener Concept for Car Example
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 57
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 58
Template Method
Motivation ähnlich wie Hook
aber feste Vorgabe von abstrakten Template-Methoden
alle Template-Methoden müssen überschrieben werden
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 59
Template Method:
House
run ()ring ()
Alarm
+ ring ()~ start ()~ stop ()alarm
Struktur
Verhalten Daten
class Alarm {void ring () {
start ();…stop ();…
} }
:House :FlashLight
:Sirene
:MailAlarm
MailAlarm
ring ()
Sirene
ring ()
FlashLight
~ start ()~ stop ()
~ start ()~ stop ()
~ start ()~ stop ()
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 60
Template Method:
House
run ()ring ()
Alarm
+ ring ()~ start ()~ stop ()alarm
Struktur
Verhalten Daten
class FlashLigth {void start () {
powerOn ();}
void stop () {powerOff ()
} }
:House :FlashLight
:Sirene
:MailAlarm
MailAlarm
ring ()
Sirene
ring ()
FlashLight
~ start ()~ stop ()
~ start ()~ stop ()
~ start ()~ stop ()
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 61
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 62
Decorator
ähnlich wie Composite mit nur einem Kind
ähnlich wie Chain-of-Responsibility
erweitere eine Strategy um zusätzliche Aktionen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 63
Decorator:
Struktur
Verhalten Daten
class MailAlarm {ring () {
sendMail();orig.ring();
} }
:House
:Sirene
:MailAlarm
MailAlarm
ring ()
House
run ()ring ()
Alarm
ring ()
Sirene
ring ()
alarm 0..1
FlashLight
ring ()
0..1 orig
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 64
Proxy
ähnlich wie Decorator
aber kein Zusatzeffekt
sondern remote, lazy oder cache Effekte
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 65
Proxy:
Struktur
Verhalten Daten
? :House
:Sirene
:MailAlarm
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 66
Adapter
ähnlich wie Decorator
aber Schnittstellenanpassung
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 67
Adapter:
Struktur
Verhalten Daten
? :House
:Sirene
:MailAlarm
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 68
Hausaufgabe:
Baut das Hausbeispiel mit einem (Objekt) Adapter für einen Mail-Alarm
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 69
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 70
Flyweight
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 71
Flyweight
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 72
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 73
Command
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 74
Command
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 75
Hausaufgabe: Command
Erstellt eine einfache GUI mit einem Fußball Icon auf einer Malfläche
Darunter 4 Knöpfe um den Ball jeweils 1 cm in jede Himmelsrichtung zu bewegen
Darunter ein Undo und ein Redo Knopf
Mit Command Pattern implementieren
Test: 10 mal bewegen, 5 Undo wieder an Pos 5, 2 Redo wieder an Pos 7, 7 Undo wieder an Pos 1
Sonderpunkte für Dragging
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 76
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 77
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 78
Factory Method:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 79
Prototype:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 80
Komplexer Prototyp
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 81
Abstract Factory:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 82
Hausaufgabe:
Abstrakte Fabrik für Autos und Garagen
Konfiguration für rote Spielzeugautos und Minigaragen
Konfiguration für blaue Nutzfahrzeuge und Flugzeughallen
vielleicht mal Spielzeugauto mit LKW-Motor und Hundehütte
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 83
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 84
Facade:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 85
Import Umkehrung:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 86
Import Umkehrung:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 87
Plugins:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 88
Daten Plugin:
Struktur
Verhalten Daten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 89
Hausaufgabe:
Baut ein Rahmenwerk, das einfach ein Fenster aufmacht
Baut ein Plugin, das in das Rahmenwerkfenster einen Button und ein Label einhängt, bei jedem Button Click soll das Label eins hoch gezählt werden.
Das Rahmenwerk bekommt eine Liste der zu ladenden Plugins als Aufrufparameter.
Achtung: das Rahmenwerk darf KEINE Compilezeitabhängigkeiten zu den Plugins haben
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 90
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 91
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 92
Reuse Architekturen:
Bibliotheken
Frameworks
Product Line Architecture
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 93
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 94
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 95
Components & Connectors Architekturen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 96
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 97
Components & Connectors Architekturen
Wiederverwendung von "Komponenten"
"Konnektoren" zur Verknüpfung und Anpassung von Komponenten
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 98
Components & Connectors Architekturen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 99
Components & Connectors Architekturen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 100
Components & Connectors Architekturen
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 101
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel 102