Design-Patterns-Katalog

Erzeugungsmuster (Creational Patterns)

Abstract Factory (Abstrakte Fabrik, siehe Abschnitt 3.1)

Bereitstellung einer Schnittstelle zum Erzeugen verwandter oder voneinander abhängiger Objektfamilien ohne die Benennung ihrer konkreten Klassen.

Builder (Erbauer, siehe Abschnitt 3.2)

Getrennte Handhabung der Erzeugungs- und Darstellungsmechanismen komplexer Objekte zwecks Generierung verschiedener Repräsentationen in einem einzigen Erzeugungsprozess.

Factory Method (Fabrikmethode, siehe Abschnitt 3.3)

Definition einer Schnittstelle zur Objekterzeugung, wobei die Bestimmung der zu instanziierenden Klasse den Unterklassen überlassen bleibt. Das Design Pattern Factory Method (Fabrikmethode) gestattet einer Klasse, die Instanziierung an Unterklassen zu delegieren.

Prototype (Prototyp, siehe Abschnitt 3.4)

Spezifikation der zu erzeugenden Objekttypen mittels einer prototypischen Instanz und Erzeugung neuer Objekte durch Kopieren dieses Prototyps.

Singleton (Singleton, siehe Abschnitt 3.5)

Sicherstellung der Existenz nur einer einzigen Klasseninstanz sowie Bereitstellung eines globalen Zugriffspunkts für diese Instanz.

Strukturmuster (Structural Patterns)

Adapter (Adapter, siehe Abschnitt 4.1)

Anpassung der Schnittstelle einer Klasse an ein anderes von den Clients erwartetes Interface. Das Design Pattern Adapter (Adapter) ermöglicht die Zusammenarbeit von Klassen, die ansonsten aufgrund der Inkompatibilität ihrer Schnittstellen nicht dazu in der Lage wären.

Bridge (Brücke, siehe Abschnitt 4.2)

Entkopplung einer Abstraktion von ihrer Implementierung, so dass beide unabhängig voneinander variiert werden können.

Composite (Kompositum, siehe Abschnitt 4.3)

Komposition von Objekten in Baumstrukturen zur Abbildung von Teil-Ganzes-Hierarchien. Das Design Pattern Composite (Kompositum) gestattet den Clients einen einheitlichen Umgang sowohl mit individuellen Objekten als auch mit Objektkompositionen.

Decorator (Dekorierer, siehe Abschnitt 4.4)

Dynamische Erweiterung der Funktionalität eines Objekts. Decorator-Objekte stellen hinsichtlich der Ergänzung einer Klasse um weitere Zuständigkeiten eine flexible Alternative zur Unterklassenbildung dar.

Facade (Fassade, siehe Abschnitt 4.5)

Bereitstellung einer einheitlichen Schnittstelle zu einem Schnittstellensatz in einem Subsystem. Das Design Pattern Facade (Fassade) definiert eine Schnittstelle höherer Ebene, die die Nutzung des Subsystems vereinfacht.

Flyweight (Fliegengewicht, siehe Abschnitt 4.6)

Gemeinsame Nutzung feingranularer Objekte, um sie auch in großer Anzahl effizient nutzen zu können.

Proxy (Proxy, siehe Abschnitt 4.7)

Bereitstellung eines vorgelagerten Stellvertreterobjekts bzw. eines Platzhalters zwecks Zugriffssteuerung eines Objekts.

Verhaltensmuster (Behavioral Patterns)

Chain of Responsibility (Zuständigkeitskette, siehe Abschnitt 5.1)

Unterbindung der Kopplung eines Request-Auslösers mit seinem Empfänger, indem mehr als ein Objekt in die Lage versetzt wird, den Request zu bearbeiten. Die empfangenden Objekte werden miteinander verkettet und der Request wird dann so lange entlang dieser Kette weitergeleitet, bis er von einem Objekt angenommen und abgearbeitet wird.

Command (Befehl, siehe Abschnitt 5.2)

Kapselung eines Requests als Objekt, um so die Parametrisierung von Clients mit verschiedenen Requests, Warteschlangen- oder Logging-Operationen sowie das Rückgängigmachen von Operationen zu ermöglichen.

Interpreter (Interpreter, siehe Abschnitt 5.3)

Definition einer Repräsentation für die Grammatik einer gegebenen Sprache und Bereitstellung eines Interpreters, der sie nutzt, um in dieser Sprache verfasste Sätze zu interpretieren.

Iterator (Iterator, siehe Abschnitt 5.4)

Bereitstellung eines sequenziellen Zugriffs auf die Elemente eines aggregierten Objekts, ohne dessen zugrunde liegende Struktur offenzulegen.

Mediator (Vermittler, siehe Abschnitt 5.5)

Definition eines Objekts, das die Interaktionsweise eines Objektsatzes in sich kapselt. Das Design Pattern Mediator (Vermittler) begünstigt lose Kopplungen, indem es die explizite Referenzierung der Objekte untereinander unterbindet und so eine individuelle Steuerung ihrer Interaktionen ermöglicht.

Memento (Memento, siehe Abschnitt 5.6)

Erfassung und Externalisierung des internen Zustands eines Objekts, ohne dessen Kapselung zu beeinträchtigen, so dass es später wieder in diesen Zustand zurückversetzt werden kann.

Observer (Beobachter, siehe Abschnitt 5.7)

Definition einer 1-zu-n-Abhängigkeit zwischen Objekten, damit im Fall einer Zustandsänderung eines Objekts alle davon abhängigen Objekte entsprechend benachrichtigt und automatisch aktualisiert werden.

State (Zustand, siehe Abschnitt 5.8)

Anpassung der Verhaltensweise eines Objekts im Fall einer internen Zustandsänderung, so dass es den Anschein hat, als hätte es seine Klasse gewechselt.

Strategy (Strategie, siehe Abschnitt 5.9)

Definition einer Familie von einzeln gekapselten, austauschbaren Algorithmen. Das Design Pattern Strategy (Strategie) ermöglicht eine variable und von den Clients unabhängige Nutzung des Algorithmus.

Template Method (Schablonenmethode, siehe Abschnitt 5.10)

Definition der Grundstruktur eines Algorithmus in einer Operation sowie Delegation einiger Ablaufschritte an Unterklassen. Das Design Pattern Template Method (Schablonenmethode) ermöglicht den Unterklassen, bestimmte Schritte eines Algorithmus zu überschreiben, ohne dessen grundlegende Struktur zu verändern.

Visitor (Besucher, siehe Abschnitt 5.11)

Darstellung einer auf die Elemente einer Objektstruktur auszuführenden Operation. Das Design Pattern Visitor (Besucher) ermöglicht die Definition einer neuen Operation, ohne die Klassen der von ihr bearbeiteten Elemente zu verändern.

Notation für Klassendiagramme

Notation für Objektdiagramme

Notation für Interaktionsdiagramme

Beziehungen der Design Patterns

Inhaltsverzeichnis

Impressum

Vorwort

Geleitwort von Grady Booch

Einleitung

Kapitel 1: Einführung​

1.1 Was ist ein Design Pattern​?

1.2 Design Patterns​ im Smalltalk MVC​​

1.3 Beschreibung der Design Patterns​

1.4 Der Design-Patterns-Katalo​​g

1.5 Aufbau des Katalog​s

1.6 Die Anwendung von Design Pattern​s zur Behebung von Designproblem​en

1.6.1 Passende Objekte​ finden

1.6.2 Objektgranularität​ bestimmen

1.6.3 Objektschnittstellen​ spezifizieren

1.6.4 Objektimplementierungen​​ spezifizieren

1.6.5 Wiederverwendungsmechanismen​ einsetzen

1.6.6 Strukturen der Laufzeit​ und beim Kompilieren abstimmen​

1.6.7 Designänderungen berücksichtige​n

1.7 Auswahl eines Design Patterns​

1.8 Anwendung eines Design Patterns​

Kapitel 2: Fallstudie: Erstellung eines Texteditors

2.1 Designprobleme​

2.2 Dokumentstruktu​r

2.2.1 Rekursive Komposition​

2.2.2 Glyphen​

2.2.3 Das Design Pattern Composite​ (Kompositum​)

2.3 Formatierun​g

2.3.1 Kapselung des Formatierungsalgorithmus​​

2.3.2 Die Unterklassen Compositor​​ und Composition​​

2.3.3 Das Design Pattern Strategy​ (Strategie​)

2.4 Ausgestaltung der Benutzeroberfläche​

2.4.1 Durchsichtige Umhüllung​ (Transparent Enclosure​)

2.4.2 Die Unterklasse MonoGlyph​​

2.4.3 Das Design Pattern Decorator​ (Dekorierer​)

2.5 Unterstützung mehrerer Look-and-Feel-Standards​

2.5.1 Abstrahierung​ der Objekterzeugung

2.5.2 Factories und Produktklassen

2.5.3 Das Design Pattern Abstract Factory​ (Abstrakte Fabrik​)

2.6 Unterstützung mehrerer Fenstersysteme​

2.6.1 Eignung des Design Patterns Abstract Factory​ (Abstrakte Fabrik​)

2.6.2 Kapselung von Implementierungsabhängigkeiten​

2.6.3 Die Klassenhierarchien​ Window​ und WindowImp​

2.6.4 Das Design Pattern Bridge​​ (Brücke​)

2.7 Userseitige Operationen​

2.7.1 Kapselung eines Requests​

2.7.2 Die Command-Klasse​​ und ihre Unterklassen

2.7.3 Die Funktion Undo​​ (Rückgängig​)

2.7.4 Befehlshistorie​​

2.7.5 Das Design Pattern Command​ (Befehl​)

2.8 Rechtschreibprüfung​ und Silbentrennung​

2.8.1 Zugriff auf verteilte Informationen

2.8.2 Kapselung von Zugriff und Traversierung

2.8.3 Die Iterator-Klasse​​ und ihre Unterklassen

2.8.4 Das Design Pattern Iterator​ (Iterator)

2.8.5 Traversierung​​ kontra Traversierungsaktionen

2.8.6 Kapselung der Analyse

2.8.7 Die Visitor-Klasse​​ und ihre Unterklassen

2.8.8 Das Design Pattern Visitor​ (Besucher​)

2.9 Zusammenfassung

Design-Patterns-Katalog

Kapitel 3: Erzeugungsmuster (Creational Patterns)​​

3.1 Abstract Factor​y (Abstrakte Fabr​ik)

3.2 Builde​r (Erbau​er)

3.3 Factory Meth​od (Fabrikmeth​ode)

3.4 Prototyp​e (Protot​yp)

3.5 Singleton (Singleton)

3.6 Weitere Erläuterungen zu den Erzeugungsmustern​

Kapitel 4: Strukturmuster (Structural Patterns)​

4.1 Adapte​r (Adapter)

4.2 Bridg​e (Brüc​ke)

4.3 Composit​e (Komposit​um)

4.4 Decorato​r (Dekorier​er)

4.5 Facad​e (Fassa​de)

4.6 Flyweigh​t (Fliegengewic​ht)

4.7 Prox​y (Proxy)

4.8 Weitere Erläuterungen zu den Strukturmustern​

4.8.1 Adapter (Adapter, siehe Abschnitt 4.1) kontra Bridge (Brücke, siehe Abschnitt 4.2)

4.8.2 Composite (Kompositum, siehe Abschnitt 4.3) kontra Decorator (Dekorierer, siehe Abschnitt 4.4) kontra Proxy (Proxy, siehe Abschnitt 4.7)

Kapitel 5: Verhaltensmuster (Behavioral Patterns)​

5.1 Chain of Responsibility​ (Zuständigkeitskette​)

5.2 Comman​d (Befe​hl)

5.3 Interprete​r (Interpreter)

5.4 Iterato​r (Iterator)

5.5 Mediato​r (Vermittl​er)

5.6 Memento (Memento)

5.7 Observer (Beobachter)

5.8 State (Zustand)

5.9 Strategy (Strategie)

5.10 Template Method (Schablonenmethode)

5.11 Visitor (Besucher)

5.12 Weitere Erläuterungen zu den Verhaltensmustern​

5.12.1 Variieren der Kapselung

5.12.2 Objekte als Argumente

5.12.3 Kommunikation: Kapseln oder Verteilen?

5.12.4 Absender und Empfänger entkoppeln

5.12.5 Zusammenfassung

Kapitel 6: Schlusswort der Autoren

6.1 Was kann man von Design Patterns erwarten?

6.1.1 Ein gemeinsames Designvokabular​

6.1.2 Eine Dokumentations- und Lernhilfe

6.1.3 Eine Ergänzung zu existierenden Methoden

6.1.4 Zielsetzungen für Refactorings

6.2 Eine kleine Kataloggeschichte

6.3 Die Pattern-Gemeinde

6.3.1 Christopher Alexanders »Muster-Sprache​​«

6.3.2 Patterns in Softwaresystemen​

6.4 Eine Einladung

6.5 Ein abschließender Gedanke

Anhang A: Glossar

Anhang B: Notationshinweise

B.1 Klassendiagramme​​

B.2 Objektdiagramme​​

B.3 Interaktionsdiagramme​​

Anhang C: Fundamentale Klassen

C.1 Die Klasse List​

C.2 Iterator​

C.3 ListIterator​

C.4 Point​

C.5 Rect​

Anhang D: Quellenverzeichnis

Design Patterns

Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Übersetzung aus dem Amerikanischen von Maren Feilen und Knut Lorenzen

Impressum

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

ISBN 978-3-8266-9904-7

1. Auflage 2015

www.mitp.de

E-Mail: mitp-verlag@sigloch.de

Telefon: +49 7953 / 7189 - 079

Telefax: +49 7953 / 7189 - 082

Authorized translation from the English language edition, entitled DESIGN PATTERNS: ELEMENTS OF REUSABLE OBJECT-ORIENTED SOFTWARE, 1st Edition, 0201633612 by GAMMA, ERICH; HELM, RICHARD, JOHNSON, RALPH; VLISSIDES, JOHN, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright © 1995 by Addison-Wesley.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. GERMAN language edition published by mitp, an imprint of Verlagsgruppe Hüthig Jehle Rehm GmbH, Copyright © 2015.

© 2015 mitp-Verlags GmbH & Co. KG

Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Lektorat: Sabine Schulz

Sprachkorrektorat: Maren Feilen, Knut Lorenzen

electronic publication: III-satz, Husby, www.drei-satz.de

Coverbild: © art_of_sun @ Fotolia.com

Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.

Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.

Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.

Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.

Für Karin
– E.G.

Für Sylvie
– R.H.

Für Faith
– R.J.

Für Dru Ann und Matthew
Josua 24:15b
– J.V.

Vorwort

Dieses Buch wird Ihnen keine Einführung in die objektorientierte Programmierung oder das Anwendungsdesign als solches bieten – denn immerhin gibt es bereits zahlreiche sehr gute Nachschlagewerke, die diese Themen ausführlich behandeln. Die Inhalte dieses Buches setzen vielmehr voraus, dass Sie mindestens eine objektorientierte Programmiersprache relativ gut beherrschen und über grundlegende Erfahrungen im objektorientierten Design verfügen, so dass Sie nicht zum nächstbesten Fachlexikon greifen müssen, wenn Begriffe wie »Typen«, »Polymorphie« oder »Schnittstellenvererbung« statt »Implementierungsvererbung« zur Sprache kommen.

Andererseits handelt es sich bei diesem Buch aber auch nicht um eine technische Abhandlung für fortgeschrittene Entwickler. Es befasst sich mit Design Patterns, sprich Entwurfsmustern, die einfache und elegante Lösungen für spezifische Problemstellungen im objektorientierten Softwaredesign anbieten. Design Patterns repräsentieren im Grunde genommen Problemlösungen, die sich in der Praxis als sinnvoll und hilfreich erwiesen haben. Sie beschreiben Designs, die man normalerweise nicht ohne Weiteres in dieser Art entwickelt. Die Patterns basieren auf zahllosen Design- und Programmrevisionen, die Softwareentwickler auf der Suche nach besseren Wiederverwendungsmöglichkeiten und größerer Flexibilität im Laufe der Zeit erarbeitet haben – und sie stellen diese Lösungen in einer konzentrierten und einfach anzuwendenden Form zur Verfügung.

Die in dem hier vorgestellten Katalog enthaltenen Patterns erfordern weder außergewöhnliche programmiersprachliche Funktionen noch irgendwelche raffinierten Programmiertricks, mit denen man Freunde und Vorgesetzte beeindrucken kann. Sie können allesamt in den standardmäßigen objektorientierten Programmiersprachen implementiert werden, sind allerdings mit etwas mehr Aufwand verbunden als Ad-hoc-Lösungen – dieser Mehraufwand wird jedoch immer mit einer deutlich besseren Wiederverwendbarkeit und höherer Flexibilität belohnt.

Wer die Arbeitsweise der Design Patterns erst einmal verstanden hat und diesbezüglich zu einem »Aha!«-Erlebnis gelangt ist, wird fortan völlig anders über das objektorientierte Design denken. Die Patterns vermitteln Ihnen Einsichten, die es Ihnen ermöglichen, Ihre Designs flexibler, modularer, wiederverwendbarer und verständlicher zu gestalten – und genau das zählt schließlich zu den Hauptgründen, sich der objektorientierten Programmierung zuzuwenden, richtig?

An dieser Stelle sei aber auch gleich angemerkt: Machen Sie sich keine Gedanken, wenn Sie den Inhalt dieses Buches nicht schon bei der ersten Lektüre vollumfänglich verstehen. Selbst wir Autoren haben nicht immer alle Zusammenhänge dessen, was wir da zu Papier gebracht haben, sofort zu 100 % verstanden! Dieses Buch ist kein »Schmöker«, den man einmal liest und dann ins Bücherregal stellt – es ist im wahrsten Sinne des Wortes ein Nachschlagewerk, von dem wir hoffen, dass Sie es zukünftig immer wieder aufschlagen werden, um neue Erkenntnisse und Anregungen für Ihre eigenen Designs zu gewinnen.

Die Fertigstellung dieses Buches hat sich recht lange hingezogen. Es hat sozusagen vier Länder »bereist«, die Hochzeiten von drei seiner Autoren und sogar die Geburten von zwei (nicht miteinander verwandten) Sprösslingen erlebt. Und es waren sehr viele Menschen an der Entstehung dieses Werkes beteiligt. Besonderer Dank gebührt in diesem Zusammenhang Bruce Anderson, Kent Beck und André Weinand für ihre Inspiration und ihre hilfreichen Ratschläge. Unser Dank richtet sich auch an all jene, die unsere Manuskriptentwürfe gelesen und kritisch kommentiert und bewertet haben: Roger Bielefeld, Grady Booch, Tom Cargill, Mashall Cline, Ralph Hyre, Brian Kernighan, Thomas Laliberty, Mark Lorenz, Arthur Riel, Doug Schmidt, Clovis Tondo, Steve Vinoski und Rebecca Wirfs-Brock. Weiterhin danken wir dem Team von Addison-Wesley für seine Hilfe und Geduld: Kate Habib, Tiffany Moore, Lisa Raffaele, Pradeepa Siva und John Wait. Ein ganz besonderer Dank geht an Carl Kessler, Danny Sabbah und Mark Wegman von IBM Research für ihre unermüdliche Unterstützung für dieses Projekt.

Selbstverständlich danken wir auch all den Menschen, die uns per Internet und auf anderen Wegen ihre Erfahrungen mit und Meinungen zu den verschiedenen Patterns mitgeteilt haben, uns ermutigt haben und uns wissen ließen, dass unsere Arbeit die Mühe wert war. Stellvertretend für all diese Menschen bedanken wir uns an dieser Stelle bei Jon Avotins, Steve Berczuk, Julian Berdych, Matthias Bohlen, John Brant, Allan Clarke, Paul Chisholm, Jens Coldewey, Dave Collins, Jim Coplien, Don Dwiggins, Gabriele Elia, Doug Felt, Brian Foote, Denis Fortin, Ward Harold, Hermann Hueni, Nayeem Islam, Bikramjit Kalra, Paul Keefer, Thomas Kofler, Doug Lea, Dan LaLiberte, James Long, Ann Louise Luu, Pundi Madhavan, Brian Marick, Robert Martin, Dave McComb, Carl McConnell, Christine Mingins, Hanspeter Mössenböck, Eric Newton, Marianne Ozkan, Roxsan Payette, Larry Podmolik, George Radin, Sita Ramakrishnan, Russ Ramirez, Alexander Ran, Dirk Riehle, Bryan Rosenburg, Aamod Sane, Duri Schmidt, Robert Seidl, Xin Shu und Bill Walker.

Wir betrachten den in diesem Buch vorgestellten Design-Pattern-Katalog keineswegs als vollständig und unveränderlich – er repräsentiert vielmehr eine Momentaufnahme unserer Überlegungen und Erwägungen in Bezug auf gutes Softwaredesign. Wir freuen uns über Meinungen und Kommentare jeder Art, sei es Kritik oder Lob zu unseren Beispielen, Hinweise auf Referenzen und Praxisbeispiele, die wir übersehen haben, oder Vorschläge für weitere Patterns, die wir ebenfalls in den Katalog hätten aufnehmen sollen. Ihre diesbezüglichen Anfragen erreichen uns per E-Mail an design-patterns@cs.uiuc.edu. Die in diesem Buch verwendeten Codebeispiele stehen unter www.mitp.de/9700 zum Download zur Verfügung oder können alternativ per E-Mail mit dem Inhalt »send design pattern source« an design-patterns-sourceics.uiuc.edu bei uns angefordert werden.

E.G., Mountain View, California

R.H., Montreal, Quebec

R.J., Urbana, Illinois

J.V., Hawthorne, New York

August 1994

Geleitwort von Grady Booch

Alle gut strukturierten objektorientierten Architekturen basieren auf Mustern, auf Englisch »Patterns« genannt. Ich persönlich bemesse die Qualität eines objektorientierten Systems im Prinzip daran, wie viel Sorgfalt die Entwickler der grundsätzlich möglichen Zusammenarbeit der einzelnen Objekte gewidmet haben. Konzentriert man sich bei der Systementwicklung vorranging auf diese Mechanismen, dann gelangt man letztendlich zu Architekturen, die kompakter, schlichter und erheblich besser zu verstehen sind, als wenn diese Muster außer Acht gelassen werden.

Die Bedeutung von Patterns für die Erstellung komplexer Systeme wurde in anderen Disziplinen schon längst erkannt. Allen voran der Architekturtheoretiker Christopher Alexander und seine Mitarbeiter gehörten zu den Ersten, die die Etablierung und Instrumentalisierung einer »Pattern Language« (dt. »Muster-Sprache«) für die Konstruktion von Gebäuden und Städten vorschlugen. Seine Ideen und die Beiträge weiterer seiner Mitstreiter haben inzwischen auch in der objektorientierten Software Community Fuß gefasst. Kurzum: Das Konzept der Design Patterns verkörpert in der Programmentwicklung das Schlüsselelement, um sich die Erfahrungen und das Wissen anderer talentierter (Software-)Architekten zunutze zu machen.

Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides erläutern in diesem Buch die Grundsätze der Design Patterns und stellen einen Katalog solcher Muster vor. Damit leistet dieses Nachschlagewerk zwei wichtige Beiträge: Zum einen veranschaulicht es nachdrücklich die Rolle, die Patterns bei der Entwicklung komplexer Systeme einnehmen können. Und zum anderen dient es als äußerst praktische Referenz für eine Sammlung wohldurchdachter Patterns, die praktizierende Entwickler bei der Gestaltung ihrer eigenen spezifischen Anwendungen nutzen können.

Ich bin stolz darauf, dass mir die Ehre zuteilwurde, mit einigen der Autoren dieses Buches unmittelbar an ihren architektonischen Designbemühungen zusammenarbeiten zu dürfen. Ich habe viel von ihnen gelernt und bin überzeugt, dass es Ihnen bei der Lektüre dieses Buches ebenso ergehen wird.

Grady Booch

Chief Scientist, Rational Software Corporation

Einleitung

Dieses Buch gliedert sich im Wesentlichen in zwei Teile. Der erste Teil umfasst die Kapitel 1 und 2 und beschreibt, was Design Patterns sind und wie sie Ihnen bei der Entwicklung objektorientierter Software von Nutzen sein können. Zudem wird ihre praktische Anwendung anhand einer ausführlichen Fallstudie demonstriert. Im zweiten Teil des Buches (die Kapitel 3, 4 und 5) wird dann der eigentliche Katalog der einzelnen Design Patterns präsentiert.

Dieser Katalog macht den größten Teil des Buches aus. Die zugehörigen Kapitel 3, 4 und 5 unterteilen die Design Patterns in drei Kategorien: Erzeugungsmuster (Creational Patterns), Strukturmuster (Structural Patterns) und Verhaltensmuster (Behavorial Patterns).

Sie können den Katalog auf verschiedene Art und Weise nutzen: Entweder lesen Sie ihn von Anfang bis Ende durch oder wechseln von Pattern zu Pattern. Oder aber Sie konzentrieren sich jeweils auf ein Kapitel, um zu ergründen, inwiefern sich die Patterns ein und derselben Kategorie voneinander unterscheiden.

Die in den einzelnen Kapiteln angegebenen Querverweise zwischen den Patterns bilden einen roten Faden durch den Katalog. Auf diese Weise können Sie sich bequem einen Überblick darüber verschaffen, in welcher Beziehung die Patterns zueinander stehen, wie sie kombiniert werden können und welche Design Patterns gut zusammenarbeiten. Die verwandtschaftlichen Beziehungen der einzelnen Design Patterns sind in Abbildung 1.2 in einer Übersicht dargestellt.

Wenn Sie möchten, können Sie beim Lesen des Katalogs aber auch problemorientiert vorgehen. So könnten Sie z. B. gleich mit dem Abschnitt 1.6 beginnen, um sich über diverse allgemeine Probleme hinsichtlich des Designs wiederverwendbarer objektorientierter Software zu informieren, und anschließend die Ausführungen zu den Design Patterns lesen, die für die jeweiligen Problemstellungen geeignet sind. Oder Sie arbeiten zuerst den gesamten Katalog durch und gehen danach problemorientiert vor, um die passenden Patterns in Ihren Projekten anzuwenden.

Wenn Sie auf dem Gebiet der objektorientierten Entwicklung noch nicht so viel Erfahrung haben, empfiehlt es sich, mit den einfachsten und geläufigsten Patterns anzufangen:

Abstract Factory (Abstrakte Fabrik, siehe Abschnitt 3.1)

Adapter (Adapter, siehe Abschnitt 4.1)

Composite (Kompositum, siehe Abschnitt 4.3)

Decorator (Dekorierer, siehe Abschnitt 4.4)

Factory Method (Fabrikmethode, siehe Abschnitt 3.3)

Observer (Beobachter, siehe Abschnitt 5.7)

Strategy (Strategie, siehe Abschnitt 5.9)

Template Method (Schablonenmethode, siehe Abschnitt 5.10)

Kaum ein objektorientiertes System kommt ohne wenigstens ein paar Patterns aus – große Systeme nutzen sogar nahezu alle der hier genannten Exemplare. Diese Auswahl wird Ihnen helfen, die Design Patterns im Besonderen und das Konzept eines guten objektorientierten Designs im Allgemeinen wirklich zu verstehen.

Kapitel 1:Einführung​

Das Entwickeln bzw. Entwerfen objektorientierter Software ist zweifellos kein leichtes Unterfangen – und das Designen wiederverwendbarer objektorientierter Software gestaltet sich sogar noch anspruchsvoller und komplexer: Neben der Bestimmung der relevanten Objekte und deren Abstrahierung zu Klassen in geeigneter Granularität müssen außerdem passende Schnittstellen und Vererbungshierarchien definiert sowie die zentralen Beziehungen zwischen den einzelnen Klassen bestimmt werden. Darüber hinaus sollte sich das Softwaredesign natürlich einerseits speziell an den jeweiligen Erfordernissen orientieren, andererseits aber gleichermaßen eine hinreichende Universalität aufweisen, um auch für zukünftige Problemstellungen und Anforderungen gewappnet zu sein. Und Designrevisionen sollten nach Möglichkeit ebenfalls vermieden oder zumindest auf ein Minimum reduziert werden.

Erfahrene objektorientierte Programmierer sind sich im Allgemeinen darüber im Klaren, dass es sehr schwierig, wenn nicht gar unmöglich ist, ein wiederverwendbares, flexibles Design gleich von Anfang an »richtig« hinzubekommen. Aus diesem Grund greifen sie häufig mehrfach auf ihre früheren Entwürfe zurück und versuchen zunächst, weitere Modifikationen zu implementieren, bevor sie ein Softwaredesign endgültig als »abgeschlossen« betrachten.

Das Erlernen und Verinnerlichen der maßgeblichen Aspekte, die ein gutes objektorientiertes Design ausmachen, erfordert viel Zeit und Geduld. Folglich fällt es erfahrenen objektorientierten Programmierern in der Regel leichter, gute Designs zu entwerfen, als weniger geübten Entwicklern, die sich nicht selten von den zahlreichen Designoptionen überfordert fühlen und daher oft doch lieber die nicht objektorientierten Techniken anwenden, die sie früher schon eingesetzt haben. Erfahrenen Programmierern ist also offenbar spezielles Wissen zu eigen, über das unerfahrene Entwicklern (noch) nicht verfügen. Doch worum genau handelt es sich dabei?

Nun, versierten Softwaredesignern ist beispielsweise bewusst, dass sie nicht ständig versuchen müssen, für jedes Problem eine völlig neue Lösung zu entwickeln. Stattdessen machen sie sich Lösungsmöglichkeiten zunutze, die sich nach ihrer persönlichen Erfahrung bereits bewährt haben – mit anderen Worten: Haben sie erst einmal gute Lösungsansätze gefunden, dann »recyceln« sie diese und wenden sie immer wieder an. Dieser Erfahrungsvorsprung zeichnet die Experten im Bereich des Softwaredesigns aus – und erklärt auch, warum viele objektorientierte Systeme häufig wiederkehrende Klassenmuster und kommunizierende Objekte enthalten. Solche Muster (engl. Patterns) beheben bestimmte Designprobleme und gestalten objektorientierte Softwareentwürfe nicht nur flexibler und eleganter, sondern gestatten letztlich überhaupt erst ihre Wiederverwendbarkeit. Sie ermöglichen den Entwicklern, neue Designs auf gelungenen Entwürfen aufzusetzen und darauf aufzubauen. Kurz gesagt: Softwaredesigner, die mit Patterns vertraut sind, können diese unmittelbar auf die jeweils vorliegenden Problemstellungen anwenden, ohne erst »das Rad neu erfinden« zu müssen.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!