"Ein Entwurfsmuster beschreibt ein bestimmtes, in einem bestimmten Kontext immer wiederkehrendes Entwurfsproblem sowie ein generisches Schema zur Lösung dieses Problems. Das Lösungsschema wird durch seine Komponenten, den Beziehungen zwischen ihnen, ihre individuellen Verantwortlichkeiten sowie durch ihr Zusammenspiel spezifiziert. Jedes Entwurfsmuster basiert auf langjähriger praktischer Erfahrung im Entwurf von Software-Systemen."
[Buschmann, 1995]
Der Begriff Entwurfsmuster ( Design Patterns ) ist, zumindest in der Informatik, noch neu (etwa fünf bis sechs Jahre) und Gegenstand der Forschung. So ist es schwer, eine eindeutige Definition des Begriffs zu geben. Die Pattern-Bewegung ist derzeit eine der dynamischsten Bewegungen in der Informatik und läuft als Schlagwort dem mittlerweile etablierten Begriff objektorientierung den Rang ab. Dabei liegt der Hauptanteil der Veröffentlichungen in Form von World-Wide-Web Seiten auf der sogenannten Pattern-Homepage6 vor. Mailing-Listen im Internet verbreiten die neusten Meldungen. Dabei ist es nahezu unmöglich den überblick zu behalten und recht schwierig die "Spreu vom Weizen" zu trennen.
Leider werden die Begriffe Patterns und Design Patterns häufig mit Begriffen wie Klasse und Framework verwechselt. Da werden zum Beispiel Klassen aus einer Klassenbibliothek zu Entwurfsmuster erhoben und Muster zu ausprogrammierten Softwarekomponenten degradiert. Das es sich bei Klassen um mehr oder weniger reale Softwarebausteine handelt und nicht um das oben zitierte, generische Problem-Lösungspaar, wird dabei meist übersehen.
Betrachtet man die Beiträge verschiedener bekannter Autoren, wie z.B. Erich Gamma , James Coplien oder Wolgang Pree , so stellt man fest, daß alle unter Entwurfsmuster etwas geringfügig anderes verstehen. Einen gemeinsamen Kontext gibt es noch nicht. "There exists no standardization of the term desgin pattern in the realm of object oriented software development." [Pree, 1994, S.60]. Daher folgen nun die Begriffsdefinitionen der Autoren, auf die sich dieses Kapitel in der Hauptsache bezieht:
"... design patterns [in this book] are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context" [Gamma et al., 1995, S. 3]. "Ein Software-Muster ist sowohl eine Beschreibung des zu implementierenden Gegenstandes als auch eine Anleitung für die Implementierung" [Coplien, 1995b, S. 53]. "..., design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development" [Pree, 1994, S. 252].
Anhand der oben aufgeführten Zitate erkennt man die teilweise beträchtlichen, teilweise aber nur geringfügigen Unterschiede in der Auffassugng von Entwurfsmustern. Deutlicher wird dies, wenn man die bisher publizierten Entwurfsmusteransätze und Methoden untereinander vergleicht. Muster existieren in den unterschiedlichsten Größenordnungen und Abstraktionsniveaus. Einige Muster betreffen die Codierung in Hochsprachen, die auch als Idiome bezeichnet werden (siehe Coding patterns in Abbschnitt 3.3). Andere wiederum, sind auf die Erstellung von Frameworks spezialisiert (siehe Metapatterns Abschnitt 3.5)..
Neben diesen, eher im Bereich der Softwaretechnik angesiedelten Mustern, werden mittlerweile auch die Bereiche der Softwareentwicklung jenseits von Analyse, Entwurf und Codierung abgedeckt. Ein Beispiel dafür ist die, unter der Pattern-Homepage zu findende, Development Process Generative Pattern Language von James Coplien , die das übergeordnete Organisationsproblem des Softwareentwicklungszyklus angeht (siehe Management- und Organisationsmuster in Abschnitt 3.7). Beispiele aus dieser Sprache sind Muster, die die Selbstfindung von Arbeitsgruppen fordern oder das Problem der Personalführung betrachten. Probleme, die in der Organisationspsychologie längst erkannt und deren Lösungen in umfangreichen Werken niedergeschrieben wurden. Allerdings wurden sie noch nie in so kurzer, treffender, vor allem auch für Nichtfachleute verständlicher Art niedergeschrieben.
Im weiteren Verlauf dieser Arbeit sollen jedoch die technischen Bereiche der Software-Entwicklung im Vordergrund stehen. Dabei wird versucht, die ähnlichkeiten und Unterschiede der Muster herauszuarbeiten und in Kategorien einzuteilen. Peter Sommerlad findet dabei die folgenden Kategorien [Sommerlad, 1996]:
Der Versuch, alle Entwurfsmuster auf diese drei oder mehr Kategorien fest aufzuteilen, scheitert jedoch an den recht fließenden übergängen. Die Zuordnung ist nicht immer eindeutig, sondern Abhängig vom Anwendungsfall.