Design Patterns (eBook)

Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Autoren)

eBook Download: PDF | EPUB

2015 | 1. Auflage
480 Seiten
MITP Verlags GmbH & Co. KG
978-3-8266-9904-7 (ISBN)

Infos

Der Bestseller von Gamma und Co. in komplett neuer Übersetzung Das Standardwerk für die objektorientierte Softwareentwicklung Zeitlose und effektive Lösungen für wiederkehrende Aufgaben im Softwaredesign Mit Design Patterns lassen sich wiederkehrende Aufgaben in der objektorientierten Softwareentwicklung effektiv lösen. Die Autoren stellen einen Katalog einfacher und prägnanter Lösungen für häufig auftretende Aufgabenstellungen vor. Mit diesen 23 Patterns können Softwareentwickler flexiblere, elegantere und vor allem auch wiederverwendbare Designs erstellen, ohne die Lösungen jedes Mal aufs Neue selbst entwickeln zu müssen. Die Autoren beschreiben zunächst, was Patterns eigentlich sind und wie sie sich beim Design objektorientierter Software einsetzen lassen. Danach werden die stets wiederkehrenden Designs systematisch benannt, erläutert, beurteilt und katalogisiert. Mit diesem Leitfaden lernen Sie, wie sich diese wichtigen Patterns in den Softwareentwicklungsprozess einfügen und wie sie zur Lösung Ihrer eigenen Designprobleme am besten eingesetzt werden. Bei jedem Pattern ist angegeben, in welchem Kontext es besonders geeignet ist und welche Konsequenzen und Kompromisse sich aus der Verwendung des Patterns im Rahmen des Gesamtdesigns ergeben. Sämtliche Patterns entstammen echten Anwendungen und beruhen auf tatsächlich existierenden Vorbildern. Außerdem ist jedes Pattern mit Codebeispielen versehen, die demonstrieren, wie es in objektorientierten Programmiersprachen wie C++ oder Smalltalk implementiert werden kann. Das Buch eignet sich nicht nur als Lehrbuch, sondern auch hervorragend als Nachschlagewerk und Referenz und erleichtert so auch besonders die Zusammenarbeit im Team. Aus dem Inhalt: Einführung Fallstudie Erzeugungsmuster Abstract Factory Builder Factory Method Prototype Singleton Strukturmuster Adapter Bridge Composite Decorator Facade Flyweight Proxy Verhaltensmuster Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Stimmen zum Buch: »Für Designer und Entwickler objektorientierter Software ist dieses Buch von großer Bedeutung! Design Patterns stellt einen geordneten Katalog bewährter Entwurfsmus-ter zur Strukturierung, Erstellung und Manipulation von Objekten vor. Am wichtigsten ist jedoch, dass die verschiedenen Design Patterns eindeutige Bezeichnungen erhalten, die ein gemeinsames Vokabular für die Arbeit im Team bereitstellen.« - Rebecca J. Wirfs-Brock, Director, Object-Technology Services, Digitalk »Design Patterns beendet die Debatte um die Wiederverwendung von Code und zeigt das entscheidende Element der Wiederverwendbarkeit von Software auf: wiederverwendbares Design. Sie werden feststellen, dass Sie diese Patterns im Nu in Ihren eigenen Designs einsetzen und wiederverwenden.« - Steve Vinoski, Software Architect

Die Autoren sind auf dem Gebiet der objektorientierten Programmierung international anerkannte Experten. Dr. Erich Gamma war maßgeblich an der Entstehung der integrierten Entwicklungsumgebung Eclipse beteiligt und leitet seit 2011 bei der Microsoft Corporation in Zürich ein Team, das die Produktion der Entwicklungsumgebung Microsoft Visual Studio unterstützt. Dr. Richard Helm wurde 2005 mit dem ACM Programming Languages Award ausgezeichnet. Heute ist er Partner und Managing Director der Boston Consulting Group in Sydney. Dr. Ralph Johnson ist Professor des Fachbereichs Informatik der Universität von Illinois in Urbana und Champaign. Dr. John Vlissides (?2005) forschte am IBM Thomas J. Watson Research Center in Hawthorne, New York.

Autor

Dr. Erich Gamma, Dr. Richard Helm, Dr. Ralph Johnson und Dr. John Vlissides sind als „Gang of Four“ weltweit anerkannte Experten auf dem Gebiet der objektorientierten Softwareentwicklung.

Inhalt

Cover 1
Titel 11
Impressum 12
Inhaltsverzeichnis 15
Vorwort 19
Geleitwort von Grady Booch 23
Einleitung 25
Kapitel 1: Einführung 27
1.1 Was ist ein Design Pattern? 29
1.2 Design Patterns im Smalltalk MVC 32
1.3 Beschreibung der Design Patterns 34
1.4 Der Design-Patterns-Katalog 36
1.5 Aufbau des Katalogs 40
1.6 Die Anwendung von Design Patterns zur Behebung von Designproblemen 43
1.6.1 Passende Objekte finden 43
1.6.2 Objektgranularität bestimmen 44
1.6.3 Objektschnittstellen spezifizieren 44
1.6.4 Objektimplementierungen spezifizieren 46
1.6.5 Wiederverwendungsmechanismen einsetzen 51
1.6.6 Strukturen der Laufzeit und beim Kompilieren abstimmen 56
1.6.7 Designänderungen berücksichtigen 58
1.7 Auswahl eines Design Patterns 65
1.8 Anwendung eines Design Patterns 67
Kapitel 2: Fallstudie: Erstellung eines Texteditors 69
2.1 Designprobleme 69
2.2 Dokumentstruktur 71
2.2.1 Rekursive Komposition 73
2.2.2 Glyphen 74
2.2.3 Das Design Pattern Composite (Kompositum) 77
2.3 Formatierung 78
2.3.1 Kapselung des Formatierungsalgorithmus 78
2.3.2 Die Unterklassen Compositor und Composition 79
2.3.3 Das Design Pattern Strategy (Strategie) 81
2.4 Ausgestaltung der Benutzeroberfläche 82
2.4.1 Durchsichtige Umhüllung (Transparent Enclosure) 82
2.4.2 Die Unterklasse MonoGlyph 84
2.4.3 Das Design Pattern Decorator (Dekorierer) 86
2.5 Unterstützung mehrerer Look-and-Feel-Standards 87
2.5.1 Abstrahierung der Objekterzeugung 87
2.5.2 Factories und Produktklassen 88
2.5.3 Das Design Pattern Abstract Factory (Abstrakte Fabrik) 91
2.6 Unterstützung mehrerer Fenstersysteme 92
2.6.1 Eignung des Design Patterns Abstract Factory (Abstrakte Fabrik) 92
2.6.2 Kapselung von Implementierungsabhängigkeiten 93
2.6.3 Die Klassenhierarchien Window und WindowImp 95
2.6.4 Das Design Pattern Bridge (Brücke) 99
2.7 Userseitige Operationen 100
2.7.1 Kapselung eines Requests 101
2.7.2 Die Command-Klasse und ihre Unterklassen 102
2.7.3 Die Funktion Undo (Rückgängig) 103
2.7.4 Befehlshistorie 104
2.7.5 Das Design Pattern Command (Befehl) 106
2.8 Rechtschreibprüfung und Silbentrennung 107
2.8.1 Zugriff auf verteilte Informationen 107
2.8.2 Kapselung von Zugriff und Traversierung 108
2.8.3 Die Iterator-Klasse und ihre Unterklassen 110
2.8.4 Das Design Pattern Iterator (Iterator) 113
2.8.5 Traversierung kontra Traversierungsaktionen 113
2.8.6 Kapselung der Analyse 114
2.8.7 Die Visitor-Klasse und ihre Unterklassen 119
2.8.8 Das Design Pattern Visitor (Besucher) 120
2.9 Zusammenfassung 121
Kapitel 3: Erzeugungsmuster (Creational Patterns) 125
3.1 Abstract Factory (Abstrakte Fabrik) 130
3.2 Builder (Erbauer) 141
3.3 Factory Method (Fabrikmethode) 151
3.4 Prototype (Prototyp) 163
3.5 Singleton (Singleton) 174
3.6 Weitere Erläuterungen zu den Erzeugungsmustern 183
Kapitel 4: Strukturmuster (Structural Patterns) 187
4.1 Adapter (Adapter) 189
4.2 Bridge (Brücke) 202
4.3 Composite (Kompositum) 214
4.4 Decorator (Dekorierer) 228
4.5 Facade (Fassade) 239
4.6 Flyweight (Fliegengewicht) 249
4.7 Proxy (Proxy) 264
4.8 Weitere Erläuterungen zu den Strukturmustern 277
4.8.1 Adapter (Adapter, siehe Abschnitt 4.1) kontra Bridge (Brücke, siehe Abschnitt 4.2) 277
4.8.2 Composite (Kompositum, siehe Abschnitt 4.3) kontra Decorator (Dekorierer, siehe Abschnitt 4.4) kontra Proxy (Proxy, siehe Abschnitt 4.7) 278
Kapitel 5: Verhaltensmuster (Behavioral Patterns) 281
5.1 Chain of Responsibility (Zuständigkeitskette) 282
5.2 Command (Befehl) 294
5.3 Interpreter (Interpreter) 306
5.4 Iterator (Iterator) 322
5.5 Mediator (Vermittler) 340
5.6 Memento (Memento) 351
5.7 Observer (Beobachter) 362
5.8 State (Zustand) 374
5.9 Strategy (Strategie) 385
5.10 Template Method (Schablonenmethode) 396
5.11 Visitor (Besucher) 402
5.12 Weitere Erläuterungen zu den Verhaltensmustern 419
5.12.1 Variieren der Kapselung 419
5.12.2 Objekte als Argumente 420
5.12.3 Kommunikation: Kapseln oder Verteilen? 420
5.12.4 Absender und Empfänger entkoppeln 421
5.12.5 Zusammenfassung 424
Kapitel 6: Schlusswort der Autoren 427
6.1 Was kann man von Design Patterns erwarten? 427
6.1.1 Ein gemeinsames Designvokabular 428
6.1.2 Eine Dokumentations- und Lernhilfe 428
6.1.3 Eine Ergänzung zu existierenden Methoden 429
6.1.4 Zielsetzungen für Refactorings 430
6.2 Eine kleine Kataloggeschichte 432
6.3 Die Pattern-Gemeinde 433
6.3.1 Christopher Alexanders »Muster-Sprache« 434
6.3.2 Patterns in Softwaresystemen 435
6.4 Eine Einladung 436
6.5 Ein abschließender Gedanke 437
Anhang A: Glossar 439
Anhang B: Notationshinweise 445
B.1 Klassendiagramme 446
B.2 Objektdiagramme 449
B.3 Interaktionsdiagramme 449
Anhang C: Fundamentale Klassen 451
C.1 Die Klasse List 451
C.2 Iterator 454
C.3 ListIterator 454
C.4 Point 455
C.5 Rect 456
Anhang D: Quellenverzeichnis 457
Stichwortverzeichnis 463

Textauszug

Kapitel 2: Fallstudie: Erstellung eines Texteditors

Dieses Kapitel dokumentiert eine Fallstudie zur Designentwicklung eines »What-You-See-Is-What-You-Get« (oder kurz »WYSIWYG​«)-Texteditors namens Lexi​. Sie demonstriert verschiedene Problemstellungen, die sich im Design von Lexi und ähnlich gearteten Anwendungen ergeben können, und zeigt auf, wie sie sich mithilfe von Design Patterns beheben lassen. Insgesamt werden zu diesem Zweck acht verschiedene Patterns eingesetzt und anhand konkreter, nachvollziehbarer Beispiele ausführlich erläutert.

Hinweis

Das Design von Lexi basiert auf dem von Paul Calder​ entwickelten Texteditor »Doc« [CL92].

Abbildung 2.1 zeigt die Benutzeroberfläche des Texteditors Lexi. Der zentrale rechteckige Anzeigebereich des Bildschirms ist für die WYSIWYG-Darstellung des Dokuments reserviert. Hier können die gewünschten Text- und Grafikelemente beliebig zusammengestellt und mit verschiedenen Formatierungsstilen ausgestattet werden. An den Bildschirmrändern befinden sich die üblichen Pulldown-Men​üs und Scrollleis​ten sowie eine Reihe von Seitensteuerungsicons, die den gezielten Aufruf einer bestimmten Dokumentseite ermöglichen.

2.1  Designprobleme​

Im Folgenden werden sieben Problemstellungen des Lexi-Designs betrachtet:

1. Dokumentstruktur​. Die Wahl der internen Darstellung des Dokuments beeinflusst nahezu jeden Aspekt des Anwendungsdesigns. Sämtliche Bearbeitungs-, Formatierungs- und Anzeigeaktivitäten sowie Textanalysen erfordern eine Traversierung, also das systematische Durchlaufen aller Strukturelemente der Oberflächendarstellung – insofern wirkt sich die Art und Weise, wie diese Informationen organisiert sind, auch auf das Design der übrigen Bestandteile von Lexi aus.

   Abb. 2.1: Die Benutzeroberfläch​e des Texteditors »Lexi«

2. Formatierung. Wie genau ordnet Lexi die Texte und Grafiken eigentlich in Zeilen und Spalten an? Welche Objekte sind für die Umsetzung der diversen Formatierungsrichtlinien zuständig? Und wie interagieren diese Richtlinien mit der internen Darstellung des Dokuments?

3. Ausgestaltung der Benutzeroberfläche. Die Benutzeroberfläche von Lexi umfasst Elemente wie Scrollleisten, Rahmen und Schlagschatten, die zur optischen Gestaltung der WYSIWYG-Oberfläche zur Verfügung stehen und während des Designprozesses in der Regel recht häufig variiert werden. Deshalb müssen sie so problemlos wie möglich hinzugefügt und entfernt werden können, ohne dass die übrigen Bestandteile der Anwendung davon beeinträchtigt werden.

4. Unterstützung mehrerer Look-and-Feel-Standards. Die Lexi-Benutzeroberfläche sollte sich möglichst leicht und ohne größere modifizierende Eingriffe an verschiedene Look-and-Feel-Standards wie Motif​ oder Presentation Manager​ (PM) anpassen lassen.

5. Unterstützung verschiedener Fenstersysteme​. Unterschiedliche Look-and-Feel-Standards werden im Allgemeinen auf verschiedenen Fenstersystemen implementiert. Das Lexi-Design sollte daher möglichst neutral und weitgehend unabhängig von einem bestimmten Fenstersystem gestaltet sein.

6. Userseitige Vorgänge. Die User steuern Lexi mithilfe verschiedener Elemente, die auf der Benutzeroberfläche zur Verfügung stehen, wie z. B. Schaltflächen und Pulldown-Menüs, deren Funktionalität​ sich über die in der Anwendung verfügbaren Objekte verteilt. Die Herausforderung hierbei besteht in der Bereitstellung eines einheitlichen Mechanismus sowohl für den Zugriff auf diese verteilte Funktionalität als auch für das Rückgängigmachen ihrer Auswirkungen.

7. Rechtschreibprüfung und Silbentrennung. In welcher Form unterstützt Lexi analytische Operationen wie beispielsweise die Rechtschreibprüfung oder die Silbentrennung? Wie lässt sich die Anzahl der Klassen minimieren, die zur Ergänzung einer neuen analytischen Funktion geändert werden müssen?

Jede dieser Designfragen impliziert neben einer Reihe von Zielsetzungen auch feste Rahmenbedingungen für deren Realisierung. Deshalb werden diese beiden Faktoren im Folgenden zunächst eingehend analysiert und als Grundlage für den Entwurf eines geeigneten Lösungsvorschlags herangezogen. Anschließend werden dann die für die einzelnen Problemstellungen und deren Lösungen jeweils relevanten Design Patterns kurz vorgestellt.

2.2  Dokumentstruktu​r

Ein Dokument stellt im Prinzip nichts anderes dar, als eine spezifische Anordnung von grundlegenden grafischen Elementen wie Zeichen, Linien, Polygonen und anderen Formen. Diese Elemente spiegeln alle inhaltlichen Informationen des Dokuments wider. Autoren begreifen sie allerdings nicht als grafische Bausteine, sondern als physische Struktur des Dokuments – also als Zeilen, Spalten, Abbildungen, Tabellen und andere Substrukturen. Und diese Substrukturen besitzen wiederum eigene Substrukturen usw.

Hinweis

Die Verfasser eines Dokuments orientieren sich überwiegend an dessen logischer Struktur, d. h. an seiner Unterteilung in Sätze, Absätze, Abschnitte und Kapitel. Der Einfachheit halber werden in der internen Darstellung dieses Beispiels jedoch keine spezifischen Daten zur logischen Struktur gespeichert. Grundsätzlich ist die hier beschriebene Designlösung allerdings auch für die Repräsentation derartiger Informationen geeignet.

Im Fall von Lexi soll die Benutzeroberfläche den Usern die direkte Bearbeitung der Substrukturen gestatten. So sollen sie zum Beispiel in der Lage sein, ein Diagramm in seiner Gesamtheit und nicht als eine Ansammlung einzelner grafischer Primitive zu behandeln. Ebenso soll auch eine Tabelle als Ganzes referenziert werden können und nicht als eine unstrukturierte Ansammlung von Text und Grafiken – dadurch bleibt die Benutzeroberfläche überschaubar und intuitiv. Um die Lexi-Implementierung mit derartigen Eigenschaften auszustatten, wird in diesem Fallbeispiel eine interne Darstellung gewählt, die der physischen Struktur des Dokuments entspricht.

Insbesondere soll sie folgende Anforderungen erfüllen:

• Die physische Struktur des Dokuments, d. h. die Anordnung von Text und Grafiken in Zeilen, Spalten, Tabellen etc., bleibt erhalten.

• Das Dokument wird visuell generiert und präsentiert.

• Die Mapping-Koordinaten der einzelnen Elemente in der internen Darstellung werden am Bildschirm angezeigt. Sie gestatten Lexi zu bestimmen, worauf sich der User bezieht, wenn er auf ein Bildschirmelement zeigt.

Darüber hinaus sind außerdem einige Rahmenbedingungen zu berücksichtigen. Zum einen soll ein einheitlicher Umgang sowohl mit Text als auch mit Grafiken möglich sein, damit die User Gelegenheit haben, Text beliebig in Grafiken einzubetten und umgekehrt. Grafiken sind also nicht als Spezialfall von Text und Text ist nicht als Spezialfall von Grafiken zu behandeln – denn das hätte redundante Formatierungs- und Manipulationsmechanismen zur Folge. Stattdessen soll hier lediglich ein einziger Mechanismus für Text und Grafiken genügen.

Und zum anderen soll die Implementierung in der internen Darstellung nicht zwischen einzelnen Elementen und Elementgruppen unterscheiden müssen. Vielmehr soll Lexi die einheitliche Behandlung von einfachen sowie von komplexen Elementen und somit beliebig vielschichtige Dokumente ermöglichen. So könnte beispielsweise das zehnte Element in Zeile 5 der Spalte 2 ein einzelnes Zeichen oder auch ein aufwendiges Diagramm mit vielen Unterelementen sein. Solange gewährleistet ist, dass sich dieses Element eigenständig zeichnen und seine Dimensionen selbst spezifizieren kann, hat seine Komplexität keinen Einfluss darauf, wie und wo es auf der Seite erscheinen wird.

Dieser zweiten Rahmenbedingung steht jedoch die Notwendigkeit entgegen, dass z. B. Textpassagen innerhalb des Dokuments auf Rechtschreibfehler, potenzielle Silbentrennstellen und Ähnliches hin überprüft werden müssen. Oftmals spielt es dabei keine Rolle, ob es sich bei dem untersuchten Element um ein einfaches oder ein komplexes Objekt handelt, in einigen Fällen sind derartige Analysen allerdings unmittelbar von der Beschaffenheit des Objekts abhängig. So wäre es beispielsweise nicht sinnvoll, ein Polygon auf Rechtschreibfehler oder Silbentrennstellen zu überprüfen. Deshalb sollten solche wie auch andere potenziell konfliktträchtige Rahmenbedingungen stets von vornherein im Design der internen Darstellung berücksichtigt werden.

2.2.1  Rekursive Komposition​

Eine allgemein gebräuchliche Technik für die Darstellung hierarchisch strukturierter Informationen ist die rekursive Komposition, die darauf basiert, dass zunehmend...

Produkt-Details

• Erscheint lt. Verlag: 26.1.2015
• Reihe/Serie: mitp Professional
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Schlagworte: Objektorientierte-Programmierung • OOP • Programmierung • Software-Entwicklung
• ISBN-10: 3-8266-9904-1 / 3826699041
• ISBN-13: 978-3-8266-9904-7 / 9783826699047