Präsentation herunterladen
Veröffentlicht von:Lies Radden Geändert vor über 10 Jahren
1
Design Pattern SS 10 Prof. Albert Zündorf
Fachgebiet für Software Engineering Wilhelmshöher Allee Kassel (Raum 1339)
2
Organisatorisches Umfang: 4 SWS teils Vorlesungen teils Übungen
Übungsbetreuung: Johannes Spohr, Sebastian Schulz Ort und Zeit: Vorlesung: Dienstags 16: :00 Raum (Erste Vorlesung: ) Übung:? In obigem Zeitraum Prüfung: Pflichtübungsaufgaben (korrigiert, bepunktet) Folienskript / Screen Videos: Design Pattern SS © 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 (1994) Patterns Home Page: st- Unified Modeling Language: Martin Hitz, Gerti Kappel: 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 SS © 2010 Albert Zündorf, University of Kassel
4
Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 2010 Albert Zündorf, University of Kassel
5
1. Einführung Ziele der Veranstaltung:
Design Know How für große Programme > LOC Grundprinzipien der Wartbarkeit und Erweiterbarkeit sicherer Umgang mit Vererbung und Delegation Grundkenntnis der wichtigsten Design Pattern neue UML 2.0 features Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
7
Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 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 SS © 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 hat Employee work (t : Task) : Product Enterprise created does Task Product Manager work (t : Task) : Product manage ( proj : Project ) : Presentation Project Presentation Design Pattern SS © 2010 Albert Zündorf, University of Kassel
10
Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee
Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS © 2010 Albert Zündorf, University of Kassel
11
Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee
Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS © 2010 Albert Zündorf, University of Kassel
12
Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee
Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS © 2010 Albert Zündorf, University of Kassel
13
Beispielsituationen … prod = e.work (t); … :Employee :Task :Employee
Enterprise Employee work (t : Task) : Product Manager manage ( proj : Project ) : Presentation hat Project Task Presentation Product created does Struktur Verhalten Daten … prod = e.work (t); … :Employee :Task :Employee :Task :Manager :Product :Project :Presentation Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
15
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 SS © 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 SS © 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 SS © 2010 Albert Zündorf, University of Kassel
18
Gliederung Einführung Design Grundprinzipien Grundlegende Pattern
Weitere Pattern Zusammenfassung Design Pattern SS © 2010 Albert Zündorf, University of Kassel
19
1. Referenzarchitektur interaktive System
QVT (Control) Generators / Interpreters GUI (Commands) Data Model GUI (Unparsing) Import/ Export Repository Design Pattern SS © 2010 Albert Zündorf, University of Kassel
20
Datenmodell mit Composite Pattern: naiv
Struktur Verhalten Daten Design Pattern SS © 2010 Albert Zündorf, University of Kassel
21
Datenmodell mit Composite Pattern: besser
Struktur Verhalten Daten Design Pattern SS © 2010 Albert Zündorf, University of Kassel
22
Datenmodell mit Composite Pattern: gut
Struktur Verhalten Daten Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
24
Composite Pattern Problem:
Struktur Verhalten Daten Design Pattern SS © 2010 Albert Zündorf, University of Kassel
25
Naiver Ansatz: Struktur Verhalten Daten
Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
27
Visitor Pattern Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
28
Visitor Pattern Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
29
Visitor Pattern Struktur Verhalten Daten
Design Pattern SS © 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 SS © 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 SS © 2010 Albert Zündorf, University of Kassel
32
Strategy Pattern ersetze if-then-else-if Ketten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
33
If-then-else-if Kette:
House run () ring () mode : int Struktur Verhalten Daten public void ring () { if (mode == SIRENE) { …} else if (mode == FLASH) { …} else if (mode == MAIL) { …} … Design Pattern SS © 2010 Albert Zündorf, University of Kassel
34
Strategy Pattern: alarm 0..1 :House :FlashLight class House {
run () ring () Alarm ring () alarm FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten :House :FlashLight class House { public void ring () { alarm.ring (); } … :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
35
Strategy Pattern Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
36
Hook Pattern (nicht im Gof-Buch)
zusätzliches Verhalten nachträglich einbauen Design Pattern SS © 2010 Albert Zündorf, University of Kassel
37
Hook Pattern: externAlarms n
House run () ring () Alarm ring () externAlarms n FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten public void ring () { storeProtocol (); for (alarm in externAlarms) { alarm.ring (); } } :House :FlashLight :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
38
Chain of Responsibility
im wesentlichen Hook aber Abbruch wenn erfolgreich bearbeitet Design Pattern SS © 2010 Albert Zündorf, University of Kassel
39
Chain of Responsibility, original
< next House run () ring () Alarm ring () alarm FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten class Alarm { public boolean ring () { if (next != null) { return next.ring(); } return false; } } :House :FlashLight :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
40
Chain of Responsibility, original :
< next House run () ring () Alarm ring () alarm FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten class FlashLight { public boolean ring () { // try it if (bulb.isReady ()) { bulb.activate (); return true; } else { super.ring (); } } } :House :FlashLight :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
41
Chain of Responsibility, besser debugbar:
House run () ring () Alarm ring () alarms n {ordered} FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten class House { public boolean ring () { boolean success = false; for (a in alarms) { success = a.ring(); if (success) return true; } return false; } } alarms[1] :House :FlashLight alarms[2] :Sirene alarms[3] :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
42
Chain of Responsibility, besser debugbar:
House run () ring () Alarm ring () alarms n {ordered} FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten class FlashLight { public boolean ring () { // try it if (bulb.isReady ()) { bulb.activate (); return true; } else { return false; } } } :House :FlashLight :Sirene :MailAlarm Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
44
Beobachtungen Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
46
State im wesentlichen Strategy
aber systematische Strategy-Änderung nach Benutzung meist Implementierung von Statecharts Design Pattern SS © 2010 Albert Zündorf, University of Kassel
47
State: red yellow green transferCar(car) / car.stop()
TraficLight state :Integer transferCar(car) Car transferCar(car) / car.setPos(…) yellow transferCar(car) / car.stop() green Struktur Verhalten Daten 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; } } } Design Pattern SS © 2010 Albert Zündorf, University of Kassel
48
State: Red TraficLight transferCar(car) Car current Yellow TLState name states Green Struktur Verhalten Daten 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"]; } } :Car :Red states["red"] states["yellow"] :Yellow :TrafficLight :Green states["green"] Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
50
Listener/Observer/Model-View-Controler
listeners > File size :Integer write(bytes[]) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) n 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 = 112 :File size = 42 Design Pattern SS © 2010 Albert Zündorf, University of Kassel
51
Listener/Observer/Model-View-Controler
listeners > File size :Integer write(bytes[]) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) n 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 = 112 :File size = 42 Design Pattern SS © 2010 Albert Zündorf, University of Kassel
52
Listener/Observer/Model-View-Controler
listeners > File size :Integer write(bytes[]) Drive usedSpace :Integer propertyChange (obj, attrName, oldVal, newVal) n Struktur Verhalten Daten class Drive { … void propertyChange (obj,attrName,oldVal,newVal){ usedSpace += newVal – oldVal; } } … :File size = 23 write ("aaaa") :Drive usedSpace = 112 :File size = 42 Design Pattern SS © 2010 Albert Zündorf, University of Kassel
53
Listener/Observer/Model-View-Controler
Drive usedSpace :Integer File size :Integer write(bytes[]) listeners > targets > n 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 = 42 :Drive usedSpace = 112 Design Pattern SS © 2010 Albert Zündorf, University of Kassel
54
Model-View-Controler/Mediator
Computer Model-View-Controler/Mediator n Drive usedSpace :Integer File size :Integer write(bytes[]) listeners > targets > n SpaceUpdater propertyChange (obj,attrName,oldVal,newVal) Struktur Verhalten Daten :Computer usedSpace = 1012 class SpaceUpdater { … void propertyChange (obj,attrName,oldVal,newVal){ for (t : targets) { t.usedSpace += newVal – oldVal; } } } … write ("aaaa") :File size = 23 :SpaceUpdater :File size = 42 :Drive usedSpace = 112 Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
56
Listener Concept for Car Example
Struktur Verhalten Daten Design Pattern SS © 2010 Albert Zündorf, University of Kassel
57
Struktur Verhalten Daten
Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
59
Template Method: alarm :House :FlashLight
+ ring () ~ start () ~ stop () House run () ring () alarm FlashLight Sirene ring () MailAlarm ring () ~ start () ~ stop () ~ start () ~ stop () ~ start () ~ stop () Struktur Verhalten Daten :House :FlashLight class Alarm { void ring () { start (); … stop (); … } } :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
60
Template Method: alarm :House :FlashLight
+ ring () ~ start () ~ stop () House run () ring () alarm FlashLight Sirene ring () MailAlarm ring () ~ start () ~ stop () ~ start () ~ stop () ~ start () ~ stop () Struktur Verhalten Daten :House :FlashLight class FlashLigth { void start () { powerOn (); } void stop () { powerOff () } } :Sirene :MailAlarm Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
63
Decorator: alarm 0..1 :House
run () ring () Alarm ring () 0..1 orig alarm FlashLight ring () Sirene ring () MailAlarm ring () Struktur Verhalten Daten :House class MailAlarm { ring () { sendMail(); orig.ring(); } } :Sirene :MailAlarm Design Pattern SS © 2010 Albert Zündorf, University of Kassel
64
Proxy ähnlich wie Decorator aber kein Zusatzeffekt
sondern remote, lazy oder cache Effekte Design Pattern SS © 2010 Albert Zündorf, University of Kassel
65
Proxy: :House ? :Sirene :MailAlarm Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
66
Adapter ähnlich wie Decorator aber Schnittstellenanpassung
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
67
Adapter: :House ? :Sirene :MailAlarm Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
68
Hausaufgabe: Baut das Hausbeispiel mit einem (Objekt) Adapter für einen Mail-Alarm Design Pattern SS © 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 SS © 2010 Albert Zündorf, University of Kassel
71
Flyweight Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
72
Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
73
Command Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
74
Command Struktur Verhalten Daten
Design Pattern SS © 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 SS © 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 SS © 2010 Albert Zündorf, University of Kassel
79
Prototype: Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
80
Komplexer Prototyp Design Pattern SS © 2010 Albert Zündorf, University of Kassel
81
Abstract Factory: Struktur Verhalten Daten
Design Pattern SS © 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 SS © 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 SS © 2010 Albert Zündorf, University of Kassel
85
Import Umkehrung: Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
86
Import Umkehrung: Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
87
Plugins: Struktur Verhalten Daten
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
88
Daten Plugin: Struktur Verhalten Daten
Design Pattern SS © 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 SS © 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 SS © 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 SS © 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 SS © 2010 Albert Zündorf, University of Kassel
98
Components & Connectors Architekturen
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
99
Components & Connectors Architekturen
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
100
Components & Connectors Architekturen
Design Pattern SS © 2010 Albert Zündorf, University of Kassel
101
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel
102
Design Pattern SS2010 © 2010 Albert Zündorf, University of Kassel
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.