Entwurfsmuster Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering Was sind Entwurfsmuster? A design pattern names, abstracts and identifies the key aspect of a common design structure that makes it uful for creating a reusable object-oriented design [Gamma95] Eine Menge von Klasn und eine Regel sie zu gebrauchen Ein Entwurfs-Beispiel, das geschickt (im Sinne von clever oder trickreich) Mechanismen der Objektorientierung auf eine bekannte Problemstellung anwendet I. allg. nicht an eine Programmiersprache gebunden (wenngleich Entwurfsmuster mit Schablonenklasn nicht in jeder objektorientierten Sprache verwendet werden können) [Gamma95]: Gamma, E. u.a., "Design Patterns, Elemets of Reusable Object-Oriented Software", Addison-Wesley, 1995 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 2
Entwurfsmuster gibt es schon lange... 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 3 Nutzen von Entwurfsmustern Wiederverwendung von Software-Entwürfen: für viele wiederkehrende Aufgabenstellungen gibt es bereits fertige Lösungen Standardisierung von Software-Entwürfen Erhöhung von Verständlichkeit von Software- Entwürfen Aber: nicht jede Zeile Implementierung muss in ein bekanntes Entwurfsmuster eingebettet werden Die verwendeten Entwurfsmuster müsn den am Projekt beteiligten Entwicklern bekannt in Falscher Einsatz von Entwurfsmustern verwirrt 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 4
Darstellung von Entwurfsmustern UML-Modelle, zumeist Klasndiagramme, teilwei Interaktionsdiagramme (speziell bei den Behavior- Pattern) Exemplarische Implementierung der wichtigen Methoden Textuelle Beschreibung Entwurfsmuster bekommen oft einen "griffigen" Namen wie z.b. Facade, Composite,... 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 5 Null-Object Problemstellung null-überprüfungen von Objektreferenzen führen zu u.u. unübersichtlichem Programmcode Auch "null-objekte" hätten u.u. ein bestimmtes Verhalten, das oft über el-zweige zu implementieren wäre TabDialog tabdialog = view.gettabdialog(i); if(tabdialog!= null) { tabdialog.open(); el... 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 6
Null-Object Die Methoden der Klas TabDialogNull sind i.allg. leer implementiert View TabDialog open() TabDialogA open() TabDialogB open() TabDialogNull open()... {... public class View... {... TabDialog gettabdialog(int index) {... Hier wird er gefunden... return new TabDialogNull(); //... Und hier nicht 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 7 Vor und Nachteile Dem null-objekt können Verhaltensmuster implementiert werden Weniger if-konstrukte Dient u.u. der Fehlervermeidung Erhöht die Zahl der Klasn Es muss eine entsprechende Vererbungshierarchie oder ein zu implementierendes Interface im Vorfeld geben 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 8
Singleton Problemstellung Es soll sichergestellt werden, dass es zu einer Klas höchstens eine Instanz gibt. Die Instanz soll global verfügbar in, d.h. es muß eine Möglichkeit für alle Objekte geben, die Instanz anzusprechen. Beispiele: Datenbank, Drucker,... Lösung 1: Instanz in globaler Variablen ablegen. Problem: verhindert nicht die mehrfache Instantiierung. Lösung 2: deklariere alle Eigenschaften der Instanz als Klasneigenschaften. Problem: keine Redefinition möglich 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 9 Singleton Idee Idee: Die Klas ist lbst dafür verantwortlich, dass es von ihr nur ein Exemplar gibt. Sie stellt auch die Instanz zur Verfügung. Struktur: die Instanz wird in der privaten Klasnvariablen theinstance gespeichert sie kann mit der Klasnmethode getinstance() angefordert werden. (Aufruf Singleton.getInstance()) Die Instanzierung von theinstance findet beim ersten Zugriff statt Singleton -theinstance : Singleton +getinstance() : Singleton +rvice() 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 10
Singleton Programmcode class Singleton { static private Singleton theinstance = null; static public Singleton getinstance() { if (theinstance == null) { theinstance = new Singleton(); return theinstance; /* Es darf keinen public-konstruktor geben (also auch keinen Default-Konstruktor). Damit Unterklasn ihn trotzdem benutzen können, wird er protected deklariert */ protected Singleton() {...... // Instanzvariablen und -methoden 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 11 Singleton Bemerkungen Überwachter Zugang zu einer einzigen Instanz Instanz braucht erst bei Bedarf erzeugt werden Keine globale Variable notwendig Die Singleton-Klas kann redefiniert werden Kann verallgemeinert werden für n Instanzen Flexibler als die Realisierung durch Klasnoperationen 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 12
Composite Problemstellung es sollen hierarchische Teil-Ganzes-Beziehungen modelliert werden einzelne Objekte (Primitive) und zusammengetzte Objekte (Container) sollen für den Verwender die gleiche Schnittstelle haben Beispiele: Dateisystem, UML: Pakete,... Lösung: gemeinsame Oberklas für Primitive und Container, die beide Eigenschaften in sich vereinigt 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 13 Composite Lösung Component add(c : Component) +children remove(c : Component) getchild(i : int) : Component operation() 0..* Leaf operation() Composite add(c : Component) remove(c : Component) getchild(i : int) : Component operation() 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 14
Composite Bemerkungen (1) Composite reicht normale Methodenaufrufe (operation()) in der Regel an alle Kinder durch, kann aber auch noch zusätzliche Operationen durchführen die Aufnahme von Composite-Operationen in Component ist praktisch (einheitl. Schnittstelle), aber auch problematisch, da ihr Aufruf auf einen Leaf nicht sinnvoll ist. nötig ist zumindest eine Default-Implementierung dier Operationen (z.b. Exception auslön), ansonsten müßte jede Leaf-Klas das lbst tun ein Verschieben in Composite kann sinnvoll in (höhere Sicherheit). In beiden Fällen muß der Verwender darauf achten, nur bei Composite-Objekten add() etc. aufzurufen. Nur bedarf es beim zweiten Fall dazu eines expliziten Casts. 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 15 Composite Bemerkungen (2) Component kann um getparent() erweitert werden, um den übergeordneten Composite referenzieren zu können. Problem: wer enthält den obersten Composite? statt mittels getchild() die Kinder einzeln verfügbar zu machen, kann nach außen auch ein externer und/oder interner Iterator über die Kinder zur Verfügung gestellt werden. Beispiel: java.awt.component Composite gehört zur Gruppe der Structural Patterns 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 16
State Problemstellung Ein Objekt soll sich abhängig von inem Zustand verschieden verhalten. Hiervon können eine oder viele Methoden betroffen in. Idee: Der Zustand wird als Klas gekaplt. Spezielle Zustands-Klasn mit überladenen Methoden implementieren die jeweilige Zustandsabhängigkeit 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 17 State: Lösung Aufruf: einstudent.dasrichtigetun(); Student Zustand dasrichtigetun() Vorlesung Pruefung Freizeit Party dasrichtigetun() dasrichtigetun() dasrichtigetun() dasrichtigetun() 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 18
State Bemerkungen Als Erweiterung könnten die Methode dasrichtigetun() ein Objekt des Folgezustandes zurückliefern Es könne leicht weitere Zustände aufgenommen werden State gehört zur Gruppe der Behavioral Patterns Dinge, die in allen Zuständen gleich gemacht werden, können in der gemeinsamen Vaterklas implementiert werden 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 19 Einteilung der Patterns Nach [Gamma95]: Creational Patterns Instanzierung von Objekten Beispiel: Singleton Structural Patterns Lösung bestimmter Strukturierungsprobleme Beispiel: Composite Behavioral Patterns Lösungen bestimmter Verhaltensaspekte Beispiel: State 09.02.2004 Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt. Software Engineering 20