17. Entwurfsmuster (Patterns)

Themen: Zur Bedeutung von Mustern; Die „klassischen“ Entwurfsmuster in der Softwareentwicklung; Warum sollte man Entwurfsmuster kennen und einsetzen?; Der richtige Umgang mit Entwurfsmustern
Folien: PDF

Zentrale Aspekte

Der Entwurf objektorientierter Software ist schwierig,
und der wiederverwendbarer Software noch schwieriger.
Muster sind bewährte (abstrakte) Lösungen für wiederkehrende Fragestellungen.
Entwurfsmuster beschreiben interagierende Objekte und Klassen
als maßgeschneiderte Lösung eines Problems.
Klar benannte Entwurfsmuster ermöglichen eine
höhere Abstraktionsebene der Softwareentwicklung.
Entwurfsmuster sind kein Selbstzweck.
Sie können zu sparsam und zu viel eingesetzt werden.

Beispiel für ein Entwurfsmuster

Im Rahmen der Vorlesung wird ein Entwurfsmuster, das „Observer-Pattern“, vorgestellt. Da im online verfügbaren Foliensatz nur das UML-Diagramm enthalten ist, nicht aber das Schema zur Verdeutlichung eines Anwendungsfalles, seien beide Abbildungen nachfolgend wiedergegeben.

Abbildung 1: **Beispiel für einen Anwendungsfall des „Observer“-Entwurfsmusters.** Es gibt mehrere unterschiedliche Ansichten bzw. Darstellungsweisen von Daten, die in einem Objekt gespeichert sind. Das Datenobjekt sollte die Ansichten benachrichtigen, wenn sich die Daten ändern, die Ansichten können die Daten vom Datenobjekt abfragen und Änderungen der Daten (z.B. durch Nutzereingaben) an das Datenobjekt zurückmelden. Für ein UML-Diagramm des „Observer“-Entwurfsmusters, das zur Umsetzung dieser Situation verwendet werden kann, vgl. Abb. 2. Die Idee stammt aus [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): *Design Patterns. Elements of Reusable Object-Oriented Software*, Addison-Wesley, Boston], S. 293

Abbildung 2: **UML-Diagramm einer Realisierungsmöglichkeit des „Observer“-Entwurfsmusters.** Es gibt zwei abstrakte Klassen (*Subject* und *Observer*) und zwei davon durch Vererbung abgeleitete konkrete Klassen (*ConcreteSubject* und *ConcreteObserver*). In einem *Subject* können beliebig viele *Observer* registriert werden, die dann bei einer Änderung benachrichtigt werden. Ein *Observer* beobachtet hingegen immer ein konkretes *Subject* und bezieht bei einer Benachrichtigung den aktuellen Zustand dieses Objektes. Das Diagramm ist gegenüber dem Beispiel in [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): *Design Patterns. Elements of Reusable Object-Oriented Software*, Addison-Wesley, Boston] S. 294 vereinfacht, es stellt nur eine *mögliche* Realisierung dieses Entwurfsmusters dar. Ein konkretes Beispiel für einen möglichen Anwendungsfall ist in Abb. 1 dargestellt.

Weiterführende Literatur

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Der „Klassiker“ zum Thema Entwurfsmuster ist mit Sicherheit das Werk der „Viererbande“: „Design Patterns“ von Gamma, Helm, Johnson und Vlissides [Gamma, 1995Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston]. Ein Buch, das zwei wesentliche Konzepte der Entwicklung objektorientiert programmierter Software zusammenführt, ist „Refactoring to Patterns“ von Joshua Kerievsky [Kerievsky, 2005Kerievsky, Joshua (2005): Refactoring to Patterns, Addison-Wesley, Boston]. Er greift gleichermaßen auf das Werk der „Viererbande“ wie auf das grundlegende Werk zum Refactoring von Martin Fowler [Fowler, 1999Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston] zurück.

Einen etwas anderen Ansatz als die „Viererbande“ verfolgt Kent Beck in „Implementation Patterns“ [Beck, 2007Beck, Kent (2007): Implementation Patterns, Addison-Wesley, Upper Saddle River, NJ]. Seine Muster decken einen wesentlich breiteren Bereich von Mustern ab als die hier vorgestellten Entwurfsmuster. Den Zusammenhang der schematischen Darstellung von Klassen und Objekten über UML und Entwurfsmustern thematisiert Craig Larman [Larman, 2005Larman, Craig (2005): Applying UML and Patterns, Prentice Hall, Upper Saddle River, New Jersey]. Darüber hinaus gibt es noch eine ganze Reihe weiterer Werke, die sich mit dem einen oder anderen speziellen Aspekt bzw. Anwendungsgebiet von Mustern befasst [Fowler, 2003Fowler, Martin (2003): Patterns of Enterprise Application Architecture, Addison Wesley, Boston, Beck, 2004Beck, Kent; Andres, Cynthia (2004): Extreme Programming Explained. Embrace Change, Addison-Wesley, Boston, Evans, 2004Evans, Eric (2004): Domain-Driven Design, Addison Wesley, Boston, Meszaros, 2007Meszaros, Gerard (2007): xUnit Test Patterns, Addison-Wesley, Boston].

Der Ausgangspunkt für die Beschäftigung mit Mustern in der Softwareentwicklung lieferte das Werk „A Pattern Language“ des Architekten, Mathematikers und Systemtheoretikers Christopher Alexander [Alexander, 1977Alexander, Christopher; Ishikawa, Sara; Silverstein, Murray (1977): A Pattern Language, Oxford University Press, New York].

Alexander, Christopher; Ishikawa, Sara; Silverstein, Murray (1977): A Pattern Language, Oxford University Press, New York
Beck, Kent; Andres, Cynthia (2004): Extreme Programming Explained. Embrace Change, Addison-Wesley, Boston
Beck, Kent (2007): Implementation Patterns, Addison-Wesley, Upper Saddle River, NJ
Evans, Eric (2004): Domain-Driven Design, Addison Wesley, Boston
Fowler, Martin (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley Longman, Boston
Fowler, Martin (2003): Patterns of Enterprise Application Architecture, Addison Wesley, Boston
Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995): Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston
Kerievsky, Joshua (2005): Refactoring to Patterns, Addison-Wesley, Boston
Larman, Craig (2005): Applying UML and Patterns, Prentice Hall, Upper Saddle River, New Jersey
Meszaros, Gerard (2007): xUnit Test Patterns, Addison-Wesley, Boston