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.
Idiome 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

Literatur

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software. Addison Wesley, Bonn 1996, ISBN 3-89319-950-0 [nicht mehr lieferbar]
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

Weblinks