Entwurfsmuster
Ein Entwurfsmuster (engl. design pattern) beschreibt eine bewährte Schablone für ein Entwurfsproblem. Es stellt damit eine wiederverwendbare Vorlage zur Problemlösung dar. Entstanden ist der Ausdruck in der Architektur, von wo er für die Softwareentwicklung übernommen wurde. In den letzten Jahren hat der Ansatz der Entwurfsmuster auch zunehmendes Interesse im Bereich der Mensch-Computer-Interaktion gefunden.
Geschichte
Der Architekt Christopher Alexander hatte in den 1970er Jahren eine Sammlung von Entwurfsmustern zusammengestellt. In der Architektur hat sich diese Idee jedoch bei weitem nicht so verbreitet wie später in der Softwareentwicklung. Kent Beck und Ward Cunningham griffen 1987 die Ideen Alexanders aus der Architektur auf und entwickelten Entwurfsmuster für die Erstellung von grafischen Benutzungsschnittstellen in Smalltalk. Ein Jahr später begann Erich Gamma mit seiner Promotion an der Universität Zürich über die generelle Übertragung dieser Methode auf die Softwareentwicklung.
Parallel dazu arbeitete James Coplien in den Jahren 1989 bis 1991 an musterähnlichen Idiomen für C++ und veröffentlichte 1991 sein Buch Advanced C++ Idioms. Erich Gamma beendete im selben Jahr seine Promotion und ging im Anschluss in die Vereinigten Staaten von Amerika, wo er zusammen mit Richard Helm, Ralph Johnson und John Vlissides das Buch Design Patterns - Elements of Reusable Object-Oriented Software herausbrachte, in dem 23 Entwurfsmuster beschrieben sind. Diese vier Autoren sind unter Entwicklern auch unter ihrem Spitznamen Gang of Four (Viererbande, kurz GoF) bekannt und verhalfen mit ihrem Buch den Entwurfsmustern zu ihrem Durchbruch. Gelegentlich wird GoF auch als Verweis für das besagte Buch verwendet.
Nutzen
Der primäre Nutzen eines Entwurfsmusters liegt in der Beschreibung einer Lösung für eine bestimmte Klasse von Entwurfsproblemen. Weiterer Nutzen ergibt sich aus der Tatsache, dass jedes Muster einen Namen hat. Dies vereinfacht die Diskussion unter Softwareentwicklern, da man abstrakt über eine Softwarestruktur sprechen kann. So sind Entwurfsmuster – im Gegensatz zu Idiomen – zunächst einmal unabhängig von der konkreten Programmiersprache.
Wenn der Einsatz von Entwurfsmustern dokumentiert wird, ergibt sich ein weiterer Nutzen dadurch, dass durch die Beschreibung des Musters ein Bezug zur dort vorhandenen Diskussion des Problemkontextes und der Vor- und Nachteile der Lösung hergestellt wird.
Dokumentation
Die Beschreibung eines Entwurfsmusters durch die Gang of Four folgt dem folgenden Schema:
- Name und Klassifikation des Musters.
- Zweck des Musters.
- Synonyme: Andere bekannte Namen des Musters.
- Motivation: (Hinter-)Gründe für den Einsatz des Musters.
- Anwendbarkeit: Einsatzbereiche für das Muster.
- Struktur: Beschreibung der allgemeinen Struktur des Musters.
- Beteiligte Akteure: Klassen, die an dem Muster beteiligt sind.
- Zusammenspiel der beteiligten Klassen.
- Konsequenzen: Welche Vor- und Nachteile gibt es?
- Implementierung: Praxisrelevante Tipps, Tricks und Techniken sowie Warnung vor Fehlern, die leicht passieren können.
- Beispielcode: Quellcodefragment, das den Einsatz des Musters zeigt.
- Praxiseinsatz: Wo wird das Muster bereits eingesetzt?
- Querverweise: Wie spielt das Muster mit anderen Mustern zusammen?
Generell sollte die Dokumentation eines Entwurfsmusters ausreichende Informationen über das Problem, welches das Muster behandelt, über den Kontext der Anwendung und über die vorgeschlagene Lösung bereitstellen. Viele Autoren lehnen ihren Aufbau an den der Beschreibungen der Gang of Four an und adaptieren sie an ihre Bedürfnisse.
Klassifikation
Die Gang of Four klassifiziert Muster nach den beiden Kriterien des Zwecks (purpose) und des Bereichs, auf den sie wirken (scope).
Nach dem Zweck des jeweiligen Musters unterscheiden sie drei Klassen: Die erste Gruppe der Erzeugungsmuster bezieht sich auf die Erzeugung von Objekten. So kann man etwa die Anzahl von erzeugten Objekten einer Klasse kontrollieren wollen, oder man will den konkreten Typ der erzeugten Objekte - abhängig von den jeweiligen Bedingungen - anpassen. Die zweite Gruppe umfasst Strukturmuster, welche eine Vereinfachung der Struktur zwischen Klassen ermöglichen sollen. Komplexe Beziehungsgeflechte können beispielsweise über vermittelnde Klassen oder Schnittstellen logisch vereinfacht werden. Die dritte Gruppe der Verhaltensmuster betrifft das Verhalten der Klassen. Hierbei handelt es sich um die größte Gruppe von Mustern. Sie beziehen sich auf die Zusammenarbeit und den Nachrichtenaustausch von Klassen.
Nach ihrem Anwendungsbereich lassen sich Muster in Klassen- und Objektmuster einteilen. Klassenmuster beschreiben Beziehungen zwischen Klassen und bauen vorrangig Vererbungsstrukturen auf. Die Strukturen sind damit zur Übersetzungszeit festgelegt. Hingegen nutzen Objektmuster vorrangig Assoziationen und Aggregationen zur Beschreibung von Beziehungen zwischen Objekten. Die durch sie beschriebenen Strukturen zwischen Objekten sind zur Laufzeit dynamisch änderbar.
Erzeugungsmuster (Creational Patterns)
Erzeugungsmuster abstrahieren Objekterzeugungsprozesse. Klassenmuster nutzen dabei Vererbung, um die Klasse des zu erzeugenden Objekts zu variieren. Objektmuster delegieren die Objekterzeugung an andere Objekte.
- Klassenmuster
- Fabrikmethode (Factory Method, Virtual Constructor)
- Objektmuster
- Abstrakte Fabrik (Abstract Factory, Kit)
- Erbauer (Builder)
- Prototyp (Prototype)
- Einzelstück (Singleton)
Strukturmuster (Structural Patterns)
Strukturmuster fassen Klassen und Objekte zu größeren Strukturen zusammen. Klassenmuster fassen dabei Schnittstellen und Implementierungen zusammen, während Objektmuster Objekte in eine Struktur einordnen. Durch Klassenmuster beschriebene Strukturen sind zur Übersetzungszeit festgelegt. Die durch Objektmuster beschriebenen Strukturen sind zur Laufzeit änderbar.
- Klassenmuster
- Adapter (Adapter, Wrapper) (Adapter mit Vererbung oder Klassenadapter)
- Objektmuster
- Adapter (Adapter, Wrapper) (Adapter mit Assoziation oder Objektadapter).
- Brücke (Bridge, Handle/Body)
- Kompositum (Composite)
- Dekorierer (Decorator, Wrapper)
- Fassade (Facade)
- Fliegengewicht (Flyweight)
- Stellvertreter (Proxy, Surrogate)
Verhaltensmuster (Behavioral Patterns)
Verhaltensmuster beschreiben die Interaktion zwischen Objekten und komplexe Kontrollflüsse. Klassenmuster teilen die Kontrolle auf verschiedene Klassen auf, Objektmuster nutzen Aggregationen.
- Klassenmuster
- Interpreter (Interpreter)
- Schablonenmethode (Template Method)
- Objektmuster
- Zuständigkeitskette (Chain of Responsibility)
- Kommando (Command, Action, Transaction)
- Iterator (Iterator, Cursor)
- Vermittler (Mediator)
- Memento (Memento, Token)
- Beobachter (Observer, Dependents, Publish-Subscribe, Listener)
- Zustand (State, Objects for States)
- Strategie (Strategy, Policy)
- Besucher (Visitor)
- Plugin (Plugin)
Andere Arten von Mustern
Die Arbeiten der Gang of Four haben viele Autoren zu weiteren Veröffentlichungen angeregt. Daraus entstand auch die Problematik, dass ein Muster sich nicht mehr ohne weiteres als Entwurfsmuster klassifizieren lässt. Vielmehr gibt es u.a. graduelle Unterschiede in der Körnigkeit von Mustern. So wird etwa das Model View Controller-Muster (MVC) von einigen als Architekturmuster, von anderen (noch) als Entwurfsmuster betrachtet.
Beispiele für von Entwurfsmustern verschiedene Arten von Mustern sind:
- Analysemuster charakterisieren typische Fälle der Anforderungsanalyse.
- Architekturmuster beschreiben typische Software-Architekturen.
- Idiom (Softwaretechnik) sind unterhalb der Ebene des Entwurfs bei der Programmierung auftretende Muster.
- Kommunikationsmuster beziehen sich auf die Kommunikationswege zwischen Personen einer Organisation.
- Organisationsmuster beschreiben Elemente der Strukturen von Organisationen.
- Antimuster beschreiben, "wie man es nicht machen sollte."
Anti-Pattern
Wo Entwurfsmuster in der Software-Entwicklung allgemein übliche und bekannte Lösungsansätze sind, um Probleme zu lösen, so sind Anti-Pattern Negativ-Beispiele von bereits durchgeführten Lösungen, die Hinweise darauf geben, wie die Aufgabenstellung besser gelöst werden könnte und sollte.
Nachdem bei der Software-Entwicklung immer mehr von positiven Erfahrung von erfolgreich abgeschlossenen Aufgabenstellungen profitiert wurde, konzentrierte man sich auch darauf, die Negativbeispiele, also wiederkehrende Fehler bei der Software-Entwicklung, zu identifizieren und zu dokumentieren.
Siehe auch
- Aspektorientierte Programmierung
- Prototyp (Technik)
- Referenzmodell
- Referenzarchitektur
- Entwurfsmuster und die Entstehung des Wikis
- Anti-Pattern
Literatur
- Erich Gamma, Richard Helm, Ralph E. Johnson: Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software, Addison Wesley in Pearson Education Deutschland, 2004, ISBN 3-8273-2199-9
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley, 1995, ISBN 0-201-63361-2
- Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksfahl-King, Shlomo Angel: Eine Muster-Sprache. Städte, Gebäude, Konstruktion. Löcker, Wien 1995, ISBN 3-85409-179-6
- Jan Borchers: A Pattern Approach to Interaction Design. John Wiley & Sons, Chichester 2001, ISBN 0-471-49828-9
- Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-orientierte Softwarearchitektur. Ein Pattern-System. Addison-Wesley-Longman, Bonn 1998, ISBN 3-8273-1282-5
- James O. Coplien: Advanced C++ Programming Styles and Idioms. Addison Wesley, 1991, ISBN 0-2015-4855-0
- Martin Fowler, David Rice, Matthew Foemmel: Patterns für Enterprise Application-Architekturen. Mitp-Verlag, 2003, ISBN 3-82661-378-3
- Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: Pattern-orientierte Softwarearchitektur. Muster für nebenläufige und vernetzte Objekte. dpunkt, Heidelberg 2002, ISBN 3-89864-142-2
Weblinks
- Der Artikel von Beck und Cunningham (Englisch)
- Das Wikiprinzip aus dem Blickwinkel der Entwurfsmusteransatzes erklärt (Englisch)