Sie sind hier
E-Book

Design Patterns

Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software

AutorErich Gamma, John Vlissides, Ralph Johnson, Richard Helm
Verlagmitp Verlags GmbH & Co. KG
Erscheinungsjahr2015
Seitenanzahl480 Seiten
ISBN9783826699030
FormatPDF/ePUB
Kopierschutzkein Kopierschutz/DRM
GerätePC/MAC/eReader/Tablet
Preis39,99 EUR
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.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

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 Scrollleisten 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äche 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  Dokumentstruktur


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

Blick ins Buch
Inhaltsverzeichnis
Cover1
Titel11
Impressum12
Inhaltsverzeichnis15
Vorwort19
Geleitwort von Grady Booch23
Einleitung25
Kapitel 1: Einführung27
1.1 Was ist ein Design Pattern?29
1.2 Design Patterns im Smalltalk MVC32
1.3 Beschreibung der Design Patterns34
1.4 Der Design-Patterns-Katalog36
1.5 Aufbau des Katalogs40
1.6 Die Anwendung von Design Patterns zur Behebung von Designproblemen43
1.6.1 Passende Objekte finden43
1.6.2 Objektgranularität bestimmen44
1.6.3 Objektschnittstellen spezifizieren44
1.6.4 Objektimplementierungen spezifizieren46
1.6.5 Wiederverwendungsmechanismen einsetzen51
1.6.6 Strukturen der Laufzeit und beim Kompilieren abstimmen56
1.6.7 Designänderungen berücksichtigen58
1.7 Auswahl eines Design Patterns65
1.8 Anwendung eines Design Patterns67
Kapitel 2: Fallstudie: Erstellung eines Texteditors69
2.1 Designprobleme69
2.2 Dokumentstruktur71
2.2.1 Rekursive Komposition73
2.2.2 Glyphen74
2.2.3 Das Design Pattern Composite (Kompositum)77
2.3 Formatierung78
2.3.1 Kapselung des Formatierungsalgorithmus78
2.3.2 Die Unterklassen Compositor und Composition79
2.3.3 Das Design Pattern Strategy (Strategie)81
2.4 Ausgestaltung der Benutzeroberfläche82
2.4.1 Durchsichtige Umhüllung (Transparent Enclosure)82
2.4.2 Die Unterklasse MonoGlyph84
2.4.3 Das Design Pattern Decorator (Dekorierer)86
2.5 Unterstützung mehrerer Look-and-Feel-Standards87
2.5.1 Abstrahierung der Objekterzeugung87
2.5.2 Factories und Produktklassen88
2.5.3 Das Design Pattern Abstract Factory (Abstrakte Fabrik)91
2.6 Unterstützung mehrerer Fenstersysteme92
2.6.1 Eignung des Design Patterns Abstract Factory (Abstrakte Fabrik)92
2.6.2 Kapselung von Implementierungsabhängigkeiten93
2.6.3 Die Klassenhierarchien Window und WindowImp95
2.6.4 Das Design Pattern Bridge (Brücke)99
2.7 Userseitige Operationen100
2.7.1 Kapselung eines Requests101
2.7.2 Die Command-Klasse und ihre Unterklassen102
2.7.3 Die Funktion Undo (Rückgängig)103
2.7.4 Befehlshistorie104
2.7.5 Das Design Pattern Command (Befehl)106
2.8 Rechtschreibprüfung und Silbentrennung107
2.8.1 Zugriff auf verteilte Informationen107
2.8.2 Kapselung von Zugriff und Traversierung108
2.8.3 Die Iterator-Klasse und ihre Unterklassen110
2.8.4 Das Design Pattern Iterator (Iterator)113
2.8.5 Traversierung kontra Traversierungsaktionen113
2.8.6 Kapselung der Analyse114
2.8.7 Die Visitor-Klasse und ihre Unterklassen119
2.8.8 Das Design Pattern Visitor (Besucher)120
2.9 Zusammenfassung121
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 Erzeugungsmustern183
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 Strukturmustern277
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 Verhaltensmustern419
5.12.1 Variieren der Kapselung419
5.12.2 Objekte als Argumente420
5.12.3 Kommunikation: Kapseln oder Verteilen?420
5.12.4 Absender und Empfänger entkoppeln421
5.12.5 Zusammenfassung424
Kapitel 6: Schlusswort der Autoren427
6.1 Was kann man von Design Patterns erwarten?427
6.1.1 Ein gemeinsames Designvokabular428
6.1.2 Eine Dokumentations- und Lernhilfe428
6.1.3 Eine Ergänzung zu existierenden Methoden429
6.1.4 Zielsetzungen für Refactorings430
6.2 Eine kleine Kataloggeschichte432
6.3 Die Pattern-Gemeinde433
6.3.1 Christopher Alexanders »Muster-Sprache«434
6.3.2 Patterns in Softwaresystemen435
6.4 Eine Einladung436
6.5 Ein abschließender Gedanke437
Anhang A: Glossar439
Anhang B: Notationshinweise445
B.1 Klassendiagramme446
B.2 Objektdiagramme449
B.3 Interaktionsdiagramme449
Anhang C: Fundamentale Klassen451
C.1 Die Klasse List451
C.2 Iterator454
C.3 ListIterator454
C.4 Point455
C.5 Rect456
Anhang D: Quellenverzeichnis457
Stichwortverzeichnis463

Weitere E-Books zum Thema: Programmiersprachen - Softwareentwicklung

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

Programmieren lernen in PHP 5

E-Book Programmieren lernen in PHP 5
Format: PDF

Mit der Version 5 erreicht PHP einen bemerkenswerten Reifegrad, der PHP zu einer festen Größe in der Welt der Webprogrammierung macht. Gerade die leichte Erlernbarkeit macht PHP zur idealen…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Weitere Zeitschriften

Ärzte Zeitung

Ärzte Zeitung

Zielgruppe:  Niedergelassene Allgemeinmediziner, Praktiker und Internisten. Charakteristik:  Die Ärzte Zeitung liefert 3 x pro Woche bundesweit an niedergelassene Mediziner ...

Bibel für heute

Bibel für heute

BIBEL FÜR HEUTE ist die Bibellese für alle, die die tägliche Routine durchbrechen wollen: Um sich intensiver mit einem Bibeltext zu beschäftigen. Um beim Bibel lesen Einblicke in Gottes ...

DGIP-intern

DGIP-intern

Mitteilungen der Deutschen Gesellschaft für Individualpsychologie e.V. (DGIP) für ihre Mitglieder Die Mitglieder der DGIP erhalten viermal jährlich das Mitteilungsblatt „DGIP-intern“ ...

dima

dima

Bau und Einsatz von Werkzeugmaschinen für spangebende und spanlose sowie abtragende und umformende Fertigungsverfahren. dima - die maschine - bietet als Fachzeitschrift die Kommunikationsplattform ...

building & automation

building & automation

Das Fachmagazin building & automation bietet dem Elektrohandwerker und Elektroplaner eine umfassende Übersicht über alle Produktneuheiten aus der Gebäudeautomation, der Installationstechnik, dem ...