Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

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.


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)


Gliederung

1. Einführung

2. Design Grundprinzipien

3. Grundlegende Pattern

4. Weitere Pattern

5. Zusammenfassung


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


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


Gliederung

1. Einführung



4. Weitere Pattern

5. Zusammenfassung



Wartbarkeit

Erweiterbarkeit

ein Ort eine Design Entscheidung / eine Funktionalität lokale Änderungen

nur lokale Auswirkungen lokaler Änderung (Module/Klassen, Interfaces, Sichtbarkeiten)

"wenig" Vererbung


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


Beispielsituationen

EnterpriseEmployee


Manager


hat

Project

Task

Presentation

Product

createddoes

…prod = e.work (t);…

Struktur

Verhalten Daten :Employee

:Employee

:Manager

:Task

:Product

:Presentation :Project

:Task


Beispielsituationen

EnterpriseEmployee


Manager


hat

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task


Beispielsituationen

EnterpriseEmployee


Manager


hat

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task


Beispielsituationen

EnterpriseEmployee


Manager


hat

Project

Task

Presentation

Product

createddoes


Struktur


:Employee

:Manager

:Task

:Product


:Task


Co- und Contravariante Redefinitionen:

wegen Substituierbarkeit:

input Parameter (Lesen) in Unterklassen nur verallgemeinern(Contravariante Redefinition)

output Parametern (Schreiben in Unterklassen nur spezialisieren(Covariante Redefinition)


Delegation:

House

run ()alarm ()

FlashLight

alarm()

Sirene

alarm()MailAlarm

alarm()

alarmDevice

Struktur

Verhalten Daten

…this.alarm();… :House

:FlashLight

:Sirene

:MailAlarm

AlarmDevice

alarm ()


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


Abgabe:

Bis

Eclipse Workspace mit Projekt mit JUnit Test

start mit einem Click

Eclipse Projekte inklusive Quellcode


Gliederung

1. Einführung



4. Weitere Pattern

5. Zusammenfassung


1. Referenzarchitektur interaktive System

Repository

Data Model

GUI(Commands)

Generators / Interpreters

QVT(Control)

Import/ Export

GUI(Unparsing)


Datenmodell mit Composite Pattern: naiv

Struktur

Verhalten Daten


Datenmodell mit Composite Pattern: besser

Struktur

Verhalten Daten


Datenmodell mit Composite Pattern: gut

Struktur

Verhalten Daten


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


Composite Pattern Problem:

Struktur

Verhalten Daten


Naiver Ansatz:

Struktur

Verhalten Daten


Visitor Pattern

rekursiver Durchlauf durch Composite Struktur

durchreichen eines Visitor Objekts

uniformerer Umgang mit Rekursionsparametern

Trennung von Durchlauf und Aktion


Visitor Pattern

Struktur

Verhalten Daten


Visitor Pattern

Struktur

Verhalten Daten


Visitor Pattern

Struktur

Verhalten Daten


Visitor Pattern Zusammenfassung

Ziemlich viele accept und visit Methoden

Double Dispatch möglich

Seperation of concern

Zustandsobjekt in der Rekursion


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


Strategy Pattern

ersetze if-then-else-if Ketten


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


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 ()


Strategy Pattern

Struktur

Verhalten Daten


Hook Pattern (nicht im Gof-Buch)

zusätzliches Verhalten nachträglich einbauen


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


Chain of Responsibility

im wesentlichen Hook

aber Abbruch wenn erfolgreich bearbeitet


< 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


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


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]


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}


Beobachtungen

typische Kombinationen von Assoc und Vererbung

Unterklassen haben KEINE neue Methoden

Unterklassen redefinieren geerbte Methoden


Beobachtungen


Hausaufgabe 4:

Baut euer Hausbeispiel aus der ersten Hausaufgabe in eine Chain of Responsibility um.

Sinnvolle Tests


State

im wesentlichen Strategy

aber systematische Strategy-Änderung nach Benutzung

meist Implementierung von Statecharts


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()


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"];

} }


Listener/Observer/Model-View-Controler/Mediator

im wesentlichen Hook

aber Einsatz zur Überwachung von Änderungen


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



Struktur

Verhalten Daten

Drive

usedSpace :Integer


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



Struktur

Verhalten Daten

Drive

usedSpace :Integer


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



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


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


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


Listener Concept for Car Example

Struktur

Verhalten Daten


Struktur

Verhalten Daten


Template Method

Motivation ähnlich wie Hook

aber feste Vorgabe von abstrakten Template-Methoden

alle Template-Methoden müssen überschrieben werden


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 ()


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 ()



Decorator

ähnlich wie Composite mit nur einem Kind

ähnlich wie Chain-of-Responsibility

erweitere eine Strategy um zusätzliche Aktionen


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


Proxy

ähnlich wie Decorator

aber kein Zusatzeffekt

sondern remote, lazy oder cache Effekte


Proxy:

Struktur

Verhalten Daten

? :House

:Sirene

:MailAlarm


Adapter

ähnlich wie Decorator

aber Schnittstellenanpassung


Adapter:

Struktur

Verhalten Daten

? :House

:Sirene

:MailAlarm


Hausaufgabe:

Baut das Hausbeispiel mit einem (Objekt) Adapter für einen Mail-Alarm



Flyweight

Struktur

Verhalten Daten


Flyweight

Struktur

Verhalten Daten


Struktur

Verhalten Daten


Command

Struktur

Verhalten Daten


Command

Struktur

Verhalten Daten


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




Factory Method:

Struktur

Verhalten Daten


Prototype:

Struktur

Verhalten Daten


Komplexer Prototyp


Abstract Factory:

Struktur

Verhalten Daten


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



Facade:

Struktur

Verhalten Daten


Import Umkehrung:

Struktur

Verhalten Daten


Import Umkehrung:

Struktur

Verhalten Daten


Plugins:

Struktur

Verhalten Daten


Daten Plugin:

Struktur

Verhalten Daten


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




Reuse Architekturen:

Bibliotheken

Frameworks

Product Line Architecture




Components & Connectors Architekturen




Wiederverwendung von "Komponenten"

"Konnektoren" zur Verknüpfung und Anpassung von Komponenten









Date post:	05-Apr-2015
Category:	Documents
Upload:	lies-radden
View:	102 times
Download:	0 times

Design Pattern SS 10 Prof. Albert Zündorf Fachgebiet für Software Engineering Wilhelmshöher Allee...

Documents