Entwurfsmuster

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Entwurfsmuster (englisch design patterns) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme sowohl in der Architektur als auch in der Softwarearchitektur und -entwicklung. Sie stellen damit eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist. In den letzten Jahren hat der Ansatz der Entwurfsmuster auch zunehmendes Interesse im Bereich der Mensch-Computer-Interaktion gefunden. Ursprünglich wurde der Begriff in der Architektur von Christopher Wolfgang Alexander verwendet.[1]

Es gibt unterschiedliche Typen von Entwurfsmustern. Hierzu zählen

  • Algorithmenstrategiemuster (englisch algorithm strategy patterns): Sie betreffen Themen der strategischen Beschreibung auf hoher Ebene, wie man die charakteristischen Eigenschaften einer Rechnerumgebung ausnutzt.
  • Rechnerische Entwurfsmuster (englisch computational design patterns)
  • Ausführungsmuster (englisch execution patterns) betreffen Themen der Anwendungsausführung mit den Strategien bei der Ausführung von Datenströmen der Arbeitsschritte (tasks) und Bausteine der Synchronisation dieser.
  • Implementierungsstrategiemuster (englisch implementation strategy patterns) betreffen Themen der Quellcodeimplementierung, um damit die
    1. Programmorganisation und
    2. allgemeinen Datenstrukturen bezüglich parallele Programmierung zu unterstützen.
  • Strukturelle Entwurfsmuster (englisch structural design patterns) betreffen Themen bezüglich zu entwickelnde Strukturen der Anwendungen auf hohem Niveau.

Inhaltsverzeichnis

Geschichte [Bearbeiten]

Der Architekt Christopher Alexander hatte in einer auf Vitruv zurückgehenden Tradition zwischen 1977–1979 eine Sammlung von Entwurfsmustern zusammengestellt.[2] Die Hauptaufgabe dieser Muster ist es, die Bewohner der zu bauenden Strukturen in den Entwurfsprozess einzubinden. Der Ansatz für Entwurfsmuster wurde von Alexander bereits 1964 in Notes on the synthesis of form dargestellt. 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 Benutzeroberflächen 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. Dort brachte er 1994 zusammen mit Richard Helm, Ralph Johnson und John Vlissides das Buch Design Patterns – Elements of Reusable Object-Oriented Software heraus, 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. Anders als Alexander, der seine Muster vor allem für Laien geschrieben hat, richten sich die GoF-Muster an Softwareentwickler und nicht an Benutzer.

Anforderungen und Nutzen [Bearbeiten]

Ein gutes Muster sollte

  • ein oder mehrere Probleme lösen,
  • ein erprobtes Konzept bieten,
  • auf realen Designs basieren,
  • über das rein Offensichtliche hinausgehen,
  • den Benutzer in den Entwurfsprozess einbinden,
  • Beziehungen aufzeigen, die tiefergehende Strukturen und Mechanismen eines Systems umfassen.

Entwurfsmuster beinhalten in der Regel Referenzen auf andere Muster. Mithilfe dieser ist es möglich, Mustersprachen zu entwickeln.

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 Entwicklern, da man abstrakt über eine Struktur sprechen kann. So sind etwa Software-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.

Nachteile [Bearbeiten]

Der erfolgreiche Einsatz von Entwurfsmustern in der Vergangenheit kann dazu verleiten, die Entwurfsmuster als Wunderwaffe und Garant für gutes Design anzusehen. Unerfahrene Entwickler können geneigt sein, möglichst viele bekannte Muster zu verwenden, und dabei übersehen, dass in ihrem Fall vielleicht eine elegantere Lösung ohne den Einsatz von Mustern möglich wäre. Entwurfsmuster garantieren nicht, dass der Entwurf gut ist. Insofern ist die Anwendung zu vieler oder ungeeigneter Entwurfsmuster ein Antimuster.

Musterkataloge [Bearbeiten]

Entwurfsmuster werden üblicherweise nach dem Vorbild der Bücher von Christopher Alexander und der Viererbande in sogenannten Musterkatalogen (engl. „Design Pattern Catalog“) gesammelt. Diese beschreiben die einzelnen Muster katalogartig anhand ihrer Eigenschaften. Diese Eigenschaften sind beispielsweise beim Buch Design Patterns – Elements of Reusable Object-Oriented Software folgende: Aufgabe, Andere Namen, Motivation, Anwendbarkeit, Struktur, Teilnehmer, Kollaborationen, Konsequenzen, Implementierung, Beispielcode, Bekannte Verwendungen, verwandte Muster.

Neben dem Entwurfsmusterkatalog der Viererbande gibt es eine Reihe weiterer Kataloge. Zu diesen zählen die Bücher Patterns of Enterprise Application Architecture, Pattern-Oriented Software Architecture, Volume 1, A System of Patterns, Refactoring To Patterns sowie die Core J2EE Patterns. Siehe Abschnitt Literatur.

Liste von Mustern [Bearbeiten]

Die folgende Tabelle von Entwurfsmustern enthält Entwurfsmuster der Viererbande (eingefärbt) sowie andere Entwurfsmuster aus anderen Katalogen. Die ersten drei Spalten stellen die Teilmengen dar, in die die Entwurfsmuster im Buch Design Patterns kategorisiert wurden. Die vierte Spalte beinhaltet solche Muster, die in die ersten drei Spalten nicht passen.

Erzeugungsmuster (Creational Design Patterns) Strukturmuster (Structural Design Patterns) Verhaltensmuster (Behavioral Design Patterns) Weitere Muster
Abstrakte Fabrik (abstract factory pattern) Adapter (adapter pattern) Beobachter (observer pattern) Business Delegate
Einzelstück (singleton pattern) Brücke (bridge pattern) Besucher (visitor pattern) Data Access Object
Erbauer (builder pattern) Dekorierer (decorator pattern) Interceptor (interceptor pattern) Datentransferobjekt (data transfer object)
Fabrikmethode (factory method pattern) Fassade (façade pattern) Interpreter (interpreter pattern) Dependency Injection
Multiton (multiton pattern) Fliegengewicht (flyweight pattern) Iterator (iterator pattern) Extension Interface
Prototyp (prototype pattern) Kompositum (composite pattern) Kommando (command pattern) Fluent Interface
  Stellvertreter (proxy pattern) Memento (memento pattern) Inversion of Control
    Nullobjekt (Null Object pattern) Model View Controller (MVC)
    Schablonenmethode (template method pattern) Model View Presenter (MVP)
    Strategie (strategy pattern) Model View ViewModel (MVVM)
    Vermittler (mediator pattern)
    Zustand (state pattern)  
    Zuständigkeitskette (chain of responsibility)  

Data Source-Architektur [Bearbeiten]

Table Data Gateway
ein Objekt, welches als Gateway zu einer Datenbanktabelle fungiert. Eine Instanz dieses Objekts behandelt dabei alle Zeilen der Tabelle.[3]
Row Data Gateway
ein Objekt, welches als Gateway zu einem einzelnen Eintrag (Zelle) in einer Datenquelle fungiert. Für jede Zeile der Datenquelle wird vom Objekt eine eigene Instanz erzeugt.[3]
Active Record
→ Hauptartikel: Active Record
ein Objekt, welches als Adapter (englisch Wrapper) zu einer Zeile in einer Datenbanktabelle oder Datenbanksicht (englisch View) dient. Der Adapter beinhaltet hierbei den Datenbankzugriff und Geschäftslogik für die Daten. Es handelt sich im Grunde um einen Row Data Gateway, welcher um die Geschäftslogik erweitert wird und deshalb sowohl Daten (Eigenschaften) als auch Verhalten (Methoden) implementiert.[3]
Data Mapper
eine Schicht von Mappern bezeichnet, die Daten zwischen Objekten im Speicher und der Datenbank vermittelt. Der Mapper ermöglicht hierbei, dass das Modell der Daten in der Datenbank und das Modell der Geschäftsobjekte unabhängig von einander, sowie unabhängig vom Mapper selbst sind.[3]

  • Table Data Gateway

  • Row Data Gateway

  • Active Record

  • Data Mapper

Domänenlogik [Bearbeiten]

Transaction Script
organisiert die Geschäftslogikschicht nach Prozeduren, wobei jede Prozedur eine einzelne Anfrage der Präsentationsschicht bearbeitet.[3]
Domain Model
stellt ein Objektmodell für die Domäne bereit, welches sowohl Verhalten als auch Daten beinhaltet.
Table Module
eine einzelne Instanz, welche die Geschäftslogik für alle Reihen in einer Datenbanktabelle oder Tabellenansicht enthält.[3]
Service Layer
stellt eine Anwendungsgrenze dar, welche eine Menge von verfügbaren Operationen bereitstellt und die Antwort der Anwendung für jede Operation koordiniert.[3]

  • Transaction Script

  • Domain Model

  • Table Module

  • Service Layer

Objekt-Relationale Verhaltensmuster [Bearbeiten]

Sequenzdiagramm von Lazy Load
Lazy Load
stellt ein Objekt bereit, welches zwar nicht alle Daten geladen hat, jedoch Methoden besitzt um die Daten bei Bedarf nachzuladen.[3]

siehe auch: Architekturmuster

Objekt-Relationale Strukturmuster [Bearbeiten]

→ Hauptartikel: Objektrelationale Abbildung
Foreign-Key-Mapping
Das Foreign-Key-Mapping bildet eine Assoziation zwischen Objekten als eine Fremdschlüsselreferenz zwischen Tabellen ab.[3]
Association-Table-Mapping
Association-Table-Mapping bildet eine n:m-Relation mit Hilfe einer Assoziationstabelle ab.[3]

  • Foreign-Key-Mapping auf skalares Feld (n:1-Mapping)

  • Foreign-Key-Mapping auf Container-Feld (1:n-Mapping)

  • Association-Table-Mapping

siehe auch: Relationale-Datenbank-Muster, Architekturmuster

Funktionale Entwurfsmuster [Bearbeiten]

Funktionale Entwurfsmuster sind Entwurfsmuster für dynamische und funktionelle Programmiersprachen.[4][5]

Zustandsmuster [Bearbeiten]

State/Event[5]
Stellt einen beliebigen vorherigen Status durch Reduzierung über gespeicherte Ereignisse wieder her.
Consequences[5]
Jedes Ereignis kann mehrere Ereignisse auslösen. Erzeugte Ereignisse können Zustandsänderungen bewirken.

Data Building-Muster [Bearbeiten]

Accumulator
Muster für Funktionen, die eine große Menge an Eingaben nimmt und kleine (skalare) Ausgaben produzieren, wie z. B. Lazy ausgewertete Sequenzen und Reduce-Funktionen.
MapReduce[5]
Eine Reduktion von linearen Strukturen.
Reduce/Combine[5]
Eine Reduktion von baumartigen Strukturen.
Rekursive Erweiterung[5]

Flusssteuerungsmuster [Bearbeiten]

Pipeline[5]
Ein Prozess mit einem einzelnen Ausführungspfad der in mehrere diskrete Schritte aufgeteilt wird, wobei jeder Schritt ein ähnlich geformtes Ergebnis liefert.
Wrapper[5]
Ein Prozess mit mehreren diskreten Schritten und einem einzelnen Hauptausführungspfad, jedoch einer möglichen Ausführungsverzweigung bei jedem Schritt. Dieses Muster darf nicht mit dem Wrapper in Objekt-Orientierten Programmiersprachen verwechselt werden.
Token[5]
Wird verwendet um eine Operation abbrechen und rückgängig machen zu können, wobei die Operation selbst keine bestimmte (benannte) Identität besitzt.
Beobachter[5]
Eine Funktion wird bei einer Liste registriert und ausgeführt, wenn sich der Zustand der Liste ändert. Die funktionale Variante entspricht im Wesentlichen der objektorientierten Version.
Strategie[5]
Eine Funktion, die abhängig von der Eingabe eine andere Funktion ausgeführt.

Andere Arten von Mustern [Bearbeiten]

Die Arbeiten der Viererbande 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 graduelle Unterschiede in der Granularität von Mustern. So wird etwa das Model-View-Controller-Muster (MVC) von einigen als Architekturmuster, von anderen (noch) als Entwurfsmuster betrachtet.

Beispiele für Muster, welche keine Entwurfsmuster sind:

  • Analysemuster charakterisieren typische Fälle der Anforderungsanalyse.
  • Architekturmuster beschreiben typische Softwarearchitekturen.
  • 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.“

Antimuster [Bearbeiten]

→ Hauptartikel: Antimuster

Wo Entwurfsmuster in der Software-Entwicklung allgemein übliche und bekannte Lösungsansätze sind, um Probleme zu lösen, so sind Antimuster Negativ-Beispiele von bereits durchgeführten Lösungen, die Hinweise darauf geben, welche Fehler vermieden werden sollten.

Nachdem bei der Softwareentwicklung immer mehr von positiven Erfahrungen 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 [Bearbeiten]

Literatur [Bearbeiten]

Weblinks [Bearbeiten]

Wikibooks Wikibooks: Entwurfsmuster – Lern- und Lehrmaterialien

Einzelnachweise [Bearbeiten]

  1. ↑ Christopher Alexander (1977/79), en:Software design pattern#History
  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
  3. ↑ a b c d e f g h i j  Martin Fowler: Patterns of Enterprise Application Architecture. Addison-Wesley-Longman, Amsterdam 15. November 2002, ISBN 0321127420.
  4. ↑ Peter Norvig: Design Patterns in Dynamic Languages. 17. März 1998, abgerufen am 6. April 2013 (PDF, PPT, HTML, englisch).
  5. ↑ a b c d e f g h i j k Stuart Sierra: Functional Design Patterns. InfoQ, 3. April 2013, abgerufen am 6. April 2013 (englisch).
0Entwurfsmuster
Viererbande
Erzeugungsmuster Abstrakte Fabrik | Erbauer | Fabrikmethode | Prototyp | Singleton
Strukturmuster Adapter | Brücke | Decorator | Fassade | Fliegengewicht | Kompositum | Stellvertreter
Verhaltensmuster Beobachter | Besucher | Interpreter | Iterator | Kommando | Memento | Schablonenmethode | Strategie | Vermittler | Zustand | Zuständigkeitskette
Weitere
Standardmuster
Erzeugungsmuster Multiton | Objektpool
Verhaltensmuster Interceptor | Nullobjekt | Protokollstapel
Andere Business Delegate | Repository | Data Access Object | Transferobjekt | Dependency Injection | Extension Interface | Fluent Interface | Inversion of Control (IoC) | Model View Presenter (MVP) | Model View ViewModel (MVVM) | Threadpool | Service Locator
Von „http://de.wikipedia.org/w/index.php?title=Entwurfsmuster&oldid=117505035“