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

Design-Patterns-Katalog

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.

Anhang D: Quellenverzeichnis

[Add94]

Addison-Wesley, Reading, MA. NEXTSTEP General Reference: Release 3, Volumes 1 und 2, 1994.

[AG90]

D.B. Anderson und S. Gossain. Hierarchy evolution and the software lifecycle. In TOOLS '90 Conference Proceedings, S. 41 – 50, Paris, Juni 1990. Prentice Hall.

[AIS+77]

Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King und Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977.

[App89]

Apple Computer, Inc., Cupertino, CA. Macintosh Programmers Workshop Pascal 3.0 Reference, 1989.

[App92]

Apple Computer, Inc., Cupertino, CA. Dylan. An object-oriented dynamic language, 1992.

[Arv91]

James Arvo. Graphics Gems II. Academic Press, Boston, MA, 1991.

[AS85]

B. Adelson und E. Soloway. The role of domain experience in software design. IEEE Transactions on Software Engineering, 11(11):1351 – 1360, 1985.

[BE93]

Andreas Birrer und Thomas Eggenschwiler. Frameworks in the financial engineering domain: An experience report. In European Conference on Object-Oriented Programming, S. 21 – 35, Kaiserslautern, Deutschland, Juli 1993. Springer-Verlag.

[BJ94]

Kent Beck und Ralph Johnson. Patterns generate architectures. In European Conference on Object-Oriented Programming, S. 139 – 149, Bologna, Italien, Juli 1994. Springer-Verlag.

[Boo94]

Grady Booch. Object-Oriented Analysis und Design with Applications. Benjamin/Cummings, Redwood City, CA, 1994. Second Edition.

[Bor8l]

A. Borning. The programming language aspects of ThingLab – a constraint-oriented simulation laboratory. ACM Transactions on Programming Languages und Systems, 3(4):343 – 387, Oktober 1981.

[Bor94]

Borland International, Inc., Scotts Valley, CA. A Technical Comparison of Borland ObjectWindows 2.0 und Microsoft MFC 2.5, 1994.

[BV90]

Grady Booch und Michael Vilot. The design of the C++ Booch components. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 1 – 11, Ottawa, Kanada, Oktober 1990. ACM Press.

[Cal93]

Paul R. Calder. Building User Interfaces with Lightweight Objects. PhD thesis, Stanford University, 1993.

[Car89]

J. Carolan. Constructing bullet-proof classes. In Proceedings C++ at Work '89. SIGS Publications, 1989.

[Car92]

Tom Cargill. C++ Programming Style. Addison-Wesley, Reading, MA, 1992.

[CIRM93]

Roy H. Campbell, Nayeem Islam, David Raila und Peter Madeany. Designing and implementing Choices: An object-oriented system in C++. Communications of the ACM, 36(9):117 – 126, September 1993.

[CL90]

Paul R. Calder und Mark A. Linton. Glyphs: Flyweight objects for user interfaces. In ACM User Interface Software Technologies Conference, S. 92 – 101, Snowbird, UT, Oktober 1990.

[CL92]

Paul R. Calder und Mark A. Linton. The object-oriented implementation of a document editor. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 154 – 165, Vancouver, British Columbia, Kanada, Oktober 1992. ACM Press.

[Coa92]

Peter Coad. Object-oriented patterns. Communications of the ACM, 35(9):152 – 159, September 1992.

[Coo92]

William R. Cook. Interfaces and specifications for the Smalltalk-80 collection classes. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 1 – 15, Vancouver, British Columbia, Kanada, Oktober 1992. ACM Press.

[Cop92]

James O. Coplien. Advanced C++ Programming Styles and Idioms. Addison-Wesley, Reading, MA, 1992.

[Cur89]

Bill Curtis. Cognitive issues in reusing software artifacts. In Ted J. Biggerstaff und Alan J. Perlis, Hrsg., Software Reusability, Volume II: Applications and Experience, S. 269 – 287. Addison-Wesley, Reading, MA, 1989.

[dCLF93]

Dennis de Champeaux, Doug Lea und Penelope Faure. Object-Oriented System Development. Addison-Wesley, Reading, MA, 1993.

[Deu89]

L. Peter Deutsch. Design reuse and frameworks in the Smalltalk-80 system. In Ted J. Biggerstaff und Alan J. Perlis, Hrsg., Software Reusability, Volume II: Applications und Experience, S. 57 – 71. Addison-Wesley, Reading, MA, 1989.

[Ede92]

D. R. Edelson. Smart pointers: They're smart, but they're not pointers. In Proceedings of the 1992 USENIX C++ Conference, S. 1 – 19, Portland, OR, August 1992. USENIX Association.

[EG92]

Thomas Eggenschwiler und Erich Gamma. The ET++SwapsManager: Using object technology in the financial engineering domain. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 166 – 178, Vancouver, British Columbia, Kanada, Oktober 1992. ACM Press.

[ES90]

Margaret A. Ellis und Bjarne Stroustrup. The Annotated C++ Reference Manual. Addison-Wesley, Reading, MA, 1990.

[Foo92]

Brian Foote. A fractal model of the lifecycles of reusable objects. OOPSLA '92 Workshop on Reuse, Oktober 1992. Vancouver, British Columbia, Kanada.

[GA89]

S. Gossain und D.B. Anderson. Designing a class hierarchy for domain representation and reusability. In TOOLS '89 Conference Proceedings, S. 201 – 210, CNIT Paris – La Defense, Frankreich, November 1989. Prentice Hall.

[Gam91]

Erich Gamma. Objekorientierte Software-Entwicklung am Beispiel von ET++: Design-Muster, Klassenbibliothek, Werkzeuge. Dissertation, Universität Zürich, Institut für Informatik, 1991.

[Gam92]

Erich Gamma. Objektorientierte Software-Entwicklung am Beispiel von ET++: Design-Muster, Klassenbibliothek, Werkzeuge. Springer-Verlag, Berlin, 1992.

[Gla90]

Andrew Glassner. Graphics Gems. Academic Press, Boston, MA, 1990.

[GM92]

M. Graham und E. Mettala. The Domain-Specific Software Architecture Program. In Proceedings of DARPA Software Technology Conference, 1992, S. 204 – 210, April 1992. Ebenfalls erschienen in CrossTalk, The Journal of Defense Software Engineering, S. 19 – 21, 32, Oktober 1992.

[GR83]

Adele J. Goldberg und David Robson. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, Reading, MA, 1983.

[HHMV92]

Richard Helm, Tien Huynh, Kim Marriott und John Vlissides. An object-oriented architecture for constraint-based graphical editing. In Proceedings of the Third Eurographics Workshop on Object-Oriented Graphics, S. 1 – 22, Champery, Schweiz, Oktober 1992. Ebenfalls verfügbar als IBM Research Division Technical Report RC 18524 (79392).

[HO87]

Daniel C. Halbert und Patrick D. O'Brien. Object-oriented development. IEEE Software, 4(5):71 – 79, September 1987.

[ION94]

IONA Technologies, Ltd., Dublin, Ireland. Programmer's Guide for Orbix, Version 1.2, 1994.

[JCJO92]

Ivar Jacobson, Magnus Christerson, Patrik Jonsson und Gunnar Overgaard. Object-Oriented Software Engineering – A Use Case Driven Approach. Addison-Wesley, Wokingham, England, 1992.

[JF88]

Ralph E. Johnson und Brian Foote. Designing reusable classes. Journal of Object-Oriented Programming, l(2):22 – 35Juni/Juli 1988.

[JML92]

Ralph E. Johnson, Carl McConnell und J. Michael Lake. The RTL system: A framework for code optimization. In Robert Giegerich und Susan L. Graham, Hrsg., Code Generation – Concepts, Tools, Techniques. Proceedings of the International Workshop on Code Generation, S. 255 – 274, Dagstuhl, Deutschland, 1992. Springer-Verlag.

[Joh92]

Ralph Johnson. Documenting frameworks using patterns. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 63 – 76, Vancouver, British Columbia, Kanada, Oktober 1992. ACM Press.

[JZ91]

Ralph E. Johnson und Jonathan Zweig. Delegation in C++. Journal of Object-Oriented Programming, 4(11):22 – 35, November 1991.

[Kir92]

David Kirk. Graphics Gems III. Harcourt, Brace, Jovanovich, Boston, MA, 1992.

[Knu73]

Donald E. Knuth. The Art of Computer Programming, Volumes 1, 2 und 3. Addison-Wesley, Reading, MA, 1973.

[Knu84]

Donald E. Knuth. The TEXbook. Addison-Wesley, Reading, MA, 1984.

[Kof93]

Thomas Kofler. Robust iterators in ET++. Structured Programming, 14:62 – 85, März 1993.

[KP88]

Glenn E. Krasner und Stephen T. Pope. A cookbook for using the modelview controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming, l(3):26 – 49, August/September 1988.

[LaL94]

Wilf LaLonde. Discovering Smalltalk. Benjamin/Cummings, Redwood City, CA, 1994.

[LCI+92]

Mark Linton, Paul Calder, John Interrante, Steven Tang und John Vlissides. InterViews Reference Manual. CSL, Stanford University, 3.1 edition, 1992.

[Lea88]

Doug Lea. libg++, the GNU C++ library. In Proceedings of the 1988 USENIX C++ Conference, S. 243 – 256, Denver, CO, Oktober 1988. USENIX Association.

[LG86]

Barbara Liskov und John Guttag. Abstraction and Specification in Program Development. McGraw-Hill, New York, 1986.

[Lie85]

Henry Lieberman. There's more to menu systems than meets the screen. In SIGGRAPH Computer Graphics, S. 181 – 189, San Francisco, CA, Juli 1985.

[Lie86]

Henry Lieberman. Using prototypical objects to implement shared behavior in object-oriented systems. In Object-Oriented Programming Systems, Languages and Applications Conference Proceedings, S. 214 – 223, Portland, OR, November 1986.

[Lin92]

Mark A. Linton. Encapsulating a C++ library. In Proceedings of the 1992 USENIX C++ Conference, S. 57 – 66, Portland, OR, August 1992. ACM Press.

[LP93]

Mark Linton und Chuck Price. Building distributed user interfaces with Fresco. In Proceedings of the 7th X Technical Conference, S. 77 – 87, Boston, MA, Januar 1993.

[LR93]

Daniel C. Lynch und Marshall T. Rose. Internet System Handbook. Addison-Wesley, Reading, MA, 1993.

[LVC89]

Mark A. Linton, John M. Vlissides und Paul R. Calder. Composing user interfaces with InterViews. Computer, 22(2):8 – 22, Februar 1989.

[Mar91]

Bruce Martin. The separation of interface und implementation in C++. In Proceedings of the 1991 USLNIX C++ Conference, S. 51 – 63, Washington, D.C., April 1991. USENIX Association.

[McC87]

Paul McCullough. Transparent forwarding: First steps. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 331 – 341, Orlando, FL, Oktober 1987. ACM Press.

[Mey88]

Bertrand Meyer. Object-Oriented Software Construction. Series in Computer Science. Prentice Hall, Englewood Cliffs, NJ, 1988.

[Mur93]

Robert B. Murray. C++ Strategies and Tactics. Addison-Wesley, Reading, MA, 1993.

[OJ90]

William F. Opdyke und Ralph E. Johnson. Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In SOOPPA Conference Proceedings, S. 145 – 161, Marist College, Poughkeepsie, NY, September 1990. ACM Press.

[OJ93]

William F. Opdyke und Ralph E. Johnson. Creating abstract superclasses by refactoring. In Proceedings of the 21st Annual Computer Science Conference (ACM CSC '93), S. 66 – 73, Indianapolis, IN, Februar 1993.

[P+88]

Andrew J. Palay et al. The Andrew Toolkit: An overview. In Proceedings of the 1988 Winter USENIX Technical Conference, S. 9 – 21, Dallas, TX, Februar 1988. USENIX Association.

[Par90]

ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990.

[Pas86]

Geoffrey A. Pascoe. Encapsulators: A new software paradigm in Smalltalk-80. In Object-Oriented Programming Systems, Languages and Applications Conference Proceedings, S. 341 – 346, Portland, OR, Oktober 1986. ACM Press.

[Pug90]

William Pugh. Skiplists: A probabilistic alternative to balanced trees. Communications of the ACM, 33(6):668 – 676, Juni 1990.

[RBP+91]

James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy und William Lorenson. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.

[Rum94]

James Rumbaugh. The life of an object model: How the object model changes during development. Journal of Object-Oriented Programming, 7(l):24 – 32, März/April 1994.

[SE84]

Elliot Soloway und Kate Ehrlich. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, 10(5)595 – 609, September 1984.

[Sha90]

Yen-Ping Shan. MoDE: A UIMS for Smalltalk. In ACM OOPSLA/ECOOP '90 Conference Proceedings, S. 258 – 268, Ottawa, Ontario, Kanada, Oktober 1990. ACM Press.

[Sny86]

Alan Snyder. Encapsulation and inheritance in object-oriented languages. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 38 – 45, Portland, OR, November 1986. ACM Press.

[SS86]

James C. Spohrer und Elliot Soloway. Novice mistakes: Are the folk wisdoms correct? Communications of the ACM, 29(7):624 – 632, Juli 1986.

[SS94]

Douglas C. Schmidt und Tatsuya Suda. The Service Configurator Framework: An extensible architecture for dynamically configuring concurrent, multi-service network daemons. In Proceeding of the Second International Workshop on Configurable Distributed Systems, S. 190 – 201, Pittsburgh, PA, März 1994. IEEE Computer Society.

[Str91]

Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley, Reading, MA, 1991. Second Edition.

[Str93]

Paul S. Strauss. IRIS Inventor, a 3D graphics toolkit. In Object-Oriented Programming Systems, Languages und Applications Conference Proceedings, S. 192 – 200, Washington, D.C., September 1993. ACM Press.

[Str94]

Bjarne Stroustrup. The Design and Evolution of C++. Addison-Wesley, Reading, MA, 1994.

[Sut63]

I.E. Sutherland. Sketchpad: A Man-Machine Graphical Communication System. PhD thesis, MIT, 1963.

[Swe85]

Richard E. Sweet. The Mesa programming environment. SIGPLAN Notices, 20(7):216 – 229, Juli 1985.

[Sym93a]

Symantec Corporation, Cupertino, CA. Bedrock Developer's Architecture Kit, 1993.

[Sym93b]

Symantec Corporation, Cupertino, CA. THINK Class Library Guide, 1993.

[Sza92]

Duane Szafron. SPECTalk: An object-oriented data specification language. In Technology of Object-Oriented Languages and Systems (TOOLS 8), S. 123 – 138, Santa Barbara, CA, August 1992. Prentice Hall.

[US87]

David Ungar und Randall B. Smith. Self: The power of simplicity. In Object-Oriented Programming Systems, Languages and Applications Conference Proceedings, S. 227 – 242, Orlando, FL, Oktober 1987. ACM Press.

[VL88]

John M. Vlissides und Mark A. Linton. Applying object-oriented design to structured graphics. In Proceedings of the 1988 USENIX C++ Conference, S. 81 – 94, Denver, CO, Oktober 1988. USENIX Association.

[VL90]

John M. Vlissides und Mark A. Linton. Unidraw: A framework for building domain-specific graphical editors. ACM Transactions on Information Systems, 8(3):237 – 268, Juli 1990.

[WBJ90]

Rebecca Wirfs-Brock und Ralph E. Johnson. A survey of current research in object-oriented design. Communications of the ACM, 33(9): 104 – 124, 1990.

[WBWW90]

Rebecca Wirfs-Brock, Brian Wilkerson und Lauren Wiener. Designing Object-Oriented Software. Prentice Hall, Englewood Cliffs, NJ, 1990.

[WGM88]

Andre Weinand, Erich Gamma und Rudolf Marty. ET++ – An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages and Applications Conference Proceedings, S. 46 – 57, San Diego, CA, September 1988. ACM Press.

Anhang C: Fundamentale Klassen

Dieser Anhang dokumentiert die grundlegenden Klassen, die in den C++-Codebeispielen zu einigen der in diesem Buch vorgestellten Design Patterns verwendet werden. Sie sind ganz bewusst einfach und minimalistisch gehalten. Dabei handelt es sich um folgende Klassen:

Einige der neueren C++-Standardtypen sind möglicherweise nicht in allen Compilern verfügbar. Sollte ein Compiler insbesondere den Typ bool nicht bereitstellen, kann dieser wie folgt manuell definiert werden:

typedef int bool;
const int true = 1;
const int false = 0;

C.1  Die Klasse List​

Das List-Klassentemplate stellt einen grundlegenden Container zur Speicherung einer geordneten Objektliste zur Verfügung. List speichert Elemente als Werte, so dass sie sowohl mit Built-in-Typen als auch mit Klasseninstanzen funktionieren. List<int> deklariert zum Beispiel eine Liste​ von int-Objekten. Die meisten Design Patterns verwenden die Klasse List jedoch zum Speichern von Pointern auf Objekte, wie beispielsweise List<Glyph*>. Auf diese Weise kann sie für heterogene Listen verwendet werden.

Komfortablerweise bietet die List-Klasse​ auch Synonyme für Stack-Operationen an, die Code, in dem die Klasse für Stacks​ genutzt wird, auch ohne die Definition einer weiteren Klasse expliziter macht:

template <class Item>
class List {
public:
    List(long size = DEFAULT_LIST_CAPACITY);
    List(List&);
    ~List() ;
    List& operator=(const List&);
 
    long Count() const;
    Item& Get(long index) const;
    Item& First() const;
    Item& Last() const;
    bool Includes(const Item&) const;
 
    void Append(const Item&);
    void Prepend(const Item&);
 
    void Remove(const Item&);
    void RemoveLast() ;
    void RemoveFirst() ;
    void RemoveAll();
 
    Item& Top() const;
    void Push(const Item&);
    Item& Pop();
};

Diese Operationen werden in den nachfolgenden Abschnitten genauer erläutert.

Erzeugung, Destruktion, Initialisierung und Zuweisung

  • List(long size)

    Initialisiert die Liste. Der Parameter size liefert einen Hinweis für die ursprüngliche Anzahl der Elemente.

  • List(List&)

    Überschreibt den Standard-Kopierkonstruktor, damit die Memberdaten korrekt initialisiert werden.

  • ~List()

    Gibt die internen Datenstrukturen, nicht jedoch die Elemente der Liste frei. Da diese Klasse nicht für die Unterklassenbildung gedacht ist, besitzt sie keinen virtuellen Destruktor.

  • List& operator=(const List&)

    Implementiert die Zuweisungsoperation für die korrekte Zuordnung der Memberdaten.

Zugriff

Die folgenden Operationen ermöglichen den grundlegenden Zugriff auf die Elemente der Liste:

  • long Count() const

    Gibt die Anzahl der in der Liste enthaltenen Objekte zurück.

  • Item& Get(long index) const

    Gibt das Objekt an dem übergebenen Index zurück.

  • Item& First() const

    Gibt das erste Objekt in der Liste zurück.

  • Item& Last() const

    Gibt das letzte Objekt in der Liste zurück.

Hinzufügen

  • void Append(const Item&)

    Fügt das Argument als letztes Element zu der Liste hinzu.

  • void Prepend(const Item&)

    Fügt das Argument als erstes Element in die Liste ein.

Entfernen

  • void Remove(const Item&)

    Entfernt das betreffende Element aus der Liste. Für diese Operation muss der Typ der Listenelemente den Vergleichsoperator == unterstützen.

  • void RemoveFirst()

    Entfernt das erste Element aus der Liste.

  • void RemoveLast()

    Entfernt das letzte Element aus der Liste.

  • void RemoveAll()

    Entfernt alle Elemente aus der Liste.

Stack-Schnittstelle​

  • Item& Top() const

    Gibt das oberste Element zurück (wenn die Liste als Stack behandelt wird).

  • void Push(const Item&)

    Legt das Element auf den Stack.

  • Item& Pop()

    Nimmt das oberste Element vom Stack.

C.2  Iterator​

Iterator ist eine abstrakte Klasse, die eine Traversierungsschnittstelle​ für Aggregate definiert:

template <class Item>
class Iterator {
public:
    virtual void First() = 0;
    virtual void Next() = 0;
    virtual bool IsDone() const = 0;
    virtual Item CurrentItem() const = 0;
protected:
    Iterator();
};

Die Operationen wirken sich folgendermaßen aus:

C.3  ListIterator​

ListIterator implementiert die Iterator-Schnittstelle​ zur Traversierung von List-Objekten. Sein Konstruktor nimmt eine Traversierungsliste als Argument entgegen:

template <class Item>
class ListIterator : public Iterator<Item> {
public:
    ListIterator(const List<Item>* aList);
 
    virtual void First();
    virtual void Next();
    virtual bool IsDone() const;
    virtual Item CurrentItem() const;
};

C.4  Point​

Die Klasse Point repräsentiert einen Punkt​ in einem zweidimensionalen kartesischen Koordinatensystem. Sie unterstützt elementare Vektorarithmetik. Die Koordinaten eines Point-Objekts sind wie folgt definiert:

typedef float Coord;

Die Operationen der Klasse Point​ sind selbsterklärend:

class Point {
public:
    static const Point Zero;
 
    Point(Coord x = 0.0, Coord y = 0.0);
 
    Coord X() const; void X(Coord x);
    Coord Y() const; void Y(Coord y);
 
    friend Point operator+(const Point&, const Point&);
    friend Point operator-(const Point&, const Point&);
    friend Point operator*(const Point&, const Point&);
    friend Point operator/(const Point&, const Point&);
 
    Point& operator+=(const Point&);
    Point& operator-=(const Point&);
    Point& operator*=(const Point&);
    Point& operator/=(const Point&);
 
    Point operator-();
 
    friend bool operator==(const Point&, const Point&);
    friend bool operator!=(const Point&, const Point&);
 
    friend ostream& operator<<(ostream&, const Point&);
    friend istream& operator>>(istream&, Point&) ;
};

Die statische Memberfunktion Zero repräsentiert Point(0, 0).

C.5  Rect​

Rect repräsentiert ein an den Achsen eines Koordinatensystems ausgerichtetes Rechteck​. Es ist durch einen Ursprungspunkt und seine Ausmaße (sprich Breite und Höhe) definiert. Die Rect-Operationen​ sind selbsterklärend:

class Rect {
public:
    static const Rect Zero;
 
    Rect(Coord x, Coord y, Coord w, Coord h);
    Rect(const Point& origin, const Point& extent);
 
    Coord Width() const; void Width(Coord);
    Coord Height() const; void Height(Coord);
    Coord Left() const; void Left(Coord);
    Coord Bottom() const; void Bottom(Coord);
 
    Point& Origin() const; void Origin(const Point&);
    Point& Extent() const; void Extent(const Point&);
 
    void MoveTo(const Point&);
    void MoveBy(const Point&);
 
    bool IsEmpty() const;
    bool Contains(const Point&) const;
};

Die statische Memberfunktion Zero entspricht dem Rechteck Rect(Point(0, 0), Point(0, 0));.

Anhang B: Notationshinweise

In diesem Buch werden wichtige Konzepte in Form von Diagrammen dargestellt. Einige davon sind eher informeller Art und werden als Bildschirmfotos oder schematische Darstellungen entsprechender Objektbäume präsentiert. Die Pattern-Beschreibungen enthalten zur Veranschaulichung der Beziehungen und Interaktionen zwischen Klassen und Objekten jedoch auch formalere Notationen, die im Folgenden ausführlich erläutert werden.

Insgesamt werden drei verschiedene Arten von Diagrammen verwendet:

  1. Ein Klassendiagramm​​ stellt Klassen, deren Struktur sowie deren statische Beziehungen zueinander dar.

  2. Ein Objektdiagramm​​ bildet eine bestimmte Objektstruktur zur Laufzeit ab.

  3. Ein Interaktionsdiagramm​​ veranschaulicht den Austausch von Requests zwischen Objekten.

Jedes Design Pattern wird zumindest durch ein Klassendiagramm dokumentiert. Die anderen Notationen kommen lediglich bedarfsweise in Ergänzung der Ausführungen zum Einsatz. Alle Klassen- und Objektdiagramme basieren auf der Object Modeling Technique​ (OMT​) [RBP+91, Rum94]. Die Interaktionsdiagramme wurden hingegen aus Objectory [JCJO92] und der Booch-Methode​ [Boo94] übernommen. Ihre Notationen stellen sich folgendermaßen dar:

Abb. B.1: Notatio​n für Klassendiagramme

Abb. B.2: Notation​ für Objektdiagramme

Abb. B.3: Notation​ für Interaktionsdiagramme

Hinweis

Die Object Modeling Technique weist große Ähnlichkeit mit der Unified Modeling Language​ (Vereinheitlichte Modellierungssprache, kurz UML​) auf.

B.1  Klassendiagramme​​

Abbildung B.4a zeigt die OMT-Notati​on für abstrakte und konkrete Klassen. Eine Klasse wird im obersten umrahmten Kasten mit fettgedrucktem Namen angezeigt. Unter dem Klassennamen sind die zentralen Operationen der Klasse angegeben. Und darunter befinden sich wiederum die möglichen zugehörigen Instanzvariablen.

Hinweis

Während sich der Begriff »Objektdiagramm« in der OMT auf Klassendiagramme bezieht, werden in diesem Buch ausschließlich Darstellungen von Objektstrukturen als »Objektdiagramme« bezeichnet.

Abb. B.4: Notatione​n für Klassendiagramme

Typinformationen sind optional anzugeben. Im Rahmen dieses Buches wird die C++-Konvention eingehalten, die vorsieht, dass der Typname dem Operationsnamen (zur Kennzeichnung des Rückgabetyps), der Instanzvariablen oder dem aktuellen Parameter vorangestellt wird. Kursiv gedruckte Bezeichnungen bedeuten, dass es sich um abstrakte Klassen oder Operationen handelt.

In manchen Fällen ist es hilfreich zu wissen, an welchen Stellen in einem Design Pattern Client-Klassen Teilnehmerklassen referenzieren. Wenn ein Pattern eine Client-Klasse als einen seiner Teilnehmer umfasst (d. h., dem Client wurde in dem Pattern eine Zuständigkeit zugewiesen), erscheint der Client als gewöhnliche Klasse. Das ist z. B. im Design Pattern Flyweight (Fliegengewicht, siehe Abschnitt 4.6) der Fall. Wenn das Pattern keine teilnehmende Client-Klasse enthält (d. h., Clients haben innerhalb des Patterns keine Zuständigkeiten), das Einbinden des Clients aber klarstellen würde, welche Teilnehmer des Patterns mit Clients interagieren, dann wird die Client-Klasse wie in Abbildung B.4b ausgegraut dargestellt. Ein Beispiel hierfür liefert das Design Pattern Proxy (Proxy, siehe Abschnitt 4.7). Ein ausgegrauter Client liefert außerdem die Bestätigung, dass der Client nicht versehentlich in der Auflistung der Teilnehmer vergessen wurde.

Abbildung B.4c veranschaulicht die diversen Beziehungen zwischen den Klassen. In der OMT-Notation wird die Klassenvererbung durch ein weißes Dreieck gekennzeichnet, das die Unterklasse (hier: LineShape) mit ihrer Basisklasse (hier: Shape) verbindet. Eine Objektreferenz, die eine Aggregations- oder Teil-Ganzes-Beziehung repräsentiert, ist als eine durchgezogene Pfeillinie mit einer Raute am Anfangspunkt dargestellt. Der Pfeil weist dabei auf die aggregierte Klasse (z. B. Shape). Eine Pfeillinie ohne Raute symbolisiert eine Kennt-Beziehung (z. B. enthält LineShape eine Referenz auf ein Color-Objekt, das mit anderen Formen geteilt werden kann). Zur Unterscheidung einer Referenz von anderen Referenzen kann zusätzlich auch der Referenzname auf der Linie angegeben sein.

Hinweis

Zwischen den Klassen definierte Assoziationsbeziehungen werden in der OMT als einfache Linien zwischen den Klassenkästen gekennzeichnet. Assoziationen sind bidirektional. Sie stellen zwar während der Analyse ein probates Modellierungsinstrument dar, sind jedoch im Prinzip zu abstrakt, um die Beziehungen in Design Patterns adäquat auszudrücken – einfach weil Assoziationen im Rahmen des Designs auf Objektreferenzen und Pointer abgebildet werden müssen. Objektreferenzen sind dagegen grundsätzlich intrinsisch gerichtet und daher für die Beziehungen, die im Zusammenhang mit den in diesem Buch vorgestellten Design Patterns von Bedeutung sind, besser geeignet. Zum Beispiel hat Drawing Kenntnis von den Shape-Klassen, während Letztere jedoch nicht wissen, in welcher Drawing-Klasse sie sich befinden. Diese Art von Beziehung lässt sich nicht allein durch Assoziationen ausdrücken.

Ebenfalls hilfreich ist es darzustellen, welche Klassen andere Klassen instanziieren. Da die OMT dies nicht unterstützt, wird in diesem Buch eine gestrichelte Pfeillinie verwendet, um solche »Erzeugt«-Beziehungen kenntlich zu machen. Der Pfeil weist auf die Klasse, die instanziiert wird. In Abbildung B.4c ist zu sehen, dass die Klasse CreationTool LineShape-Objekte erzeugt.

Die OMT definiert außerdem einen gefüllten Kreis, um »mehr als eins« anzuzeigen. Erscheint dieser Kreis am Kopfende einer Referenz, bedeutet dies, dass mehrere Objekte referenziert oder aggregiert werden.

Und schließlich wurde die OMT-Notation noch um Pseudocode-Annotationen erweitert, um die Skizzierung von Operationsimplementierungen zu ermöglichen. Abbildung B.4d zeigt die Pseudocode-Annotation der Draw-Operation der Drawing-Klasse.

B.2  Objektdiagramme​​

Ein Objektdiagramm zeigt ausschließlich Instanzen. Es stellt eine Momentaufnahme der Objekte in einem Design Pattern dar. Die Objekte sind mit »aName« bezeichnet, wobei »Name« die Klasse des Objekts angibt. Das Symbol für ein Objekt (in leicht modifizierter Form aus der Standard-OMT übernommen) ist ein Kasten mit abgerundeten Ecken, in dem der Objektname durch eine Trennlinie von möglichen Objektreferenzen separiert ist. Die von dem Objekt ausgehenden Pfeile kennzeichnen die referenzierten Objekte (siehe Abbildung B.5):

Abb. B.5: Notatio​n für Objektdiagramme

B.3  Interaktionsdiagramme​​

Ein Interaktionsdiagramm veranschaulicht die Abfolge der Request-Ausführung zwischen den Objekten. Das in Abbildung B.6 dargestellte Interaktionsdiagramm zeigt die Ergänzung eines Shape-Objekts zu Drawing:

Abb. B.6: Notatio​n für Interaktionsdiagramme

Die Zeitschiene in einem Interaktionsdiagramm verläuft von oben nach unten. Eine durchgezogene vertikale Linie gibt die Lebensdauer eines bestimmten Objekts an. Die Namenskonvention für Objekte entspricht der in Objektdiagrammen: Dem Klassennamen wird der Buchstabe »a« vorangestellt (z. B. aShape). Wenn das Objekt nicht vor Beginn der Zeitaufzeichnung in dem Diagramm instanziiert wird, wird bis zum Zeitpunkt der Erzeugung eine gestrichelte Linie verwendet.

Ein vertikales Rechteck gibt an, dass ein Objekt aktiv ist bzw. einen Request bearbeitet. Die Operation kann auch Requests an andere Objekte weiterleiten. Dies wird durch einen horizontalen Pfeil angezeigt, der auf das empfangende Objekt weist. Oberhalb des Pfeils ist die Bezeichnung des Requests angegeben. Ein Request zur Erzeugung eines Objekts wird durch eine gestrichelte Pfeillinie gekennzeichnet. Richtet sie ein Request an das sendende Objekt, wird dies durch einen auf das Objekt zurückweisenden Pfeil dargestellt.

In Abbildung B.6 ist zu sehen, dass der erste Request von aCreationTool die Erzeugung von aLineShape anweist. Später wird aLineShape mithilfe der Operation Add zu aDrawing hinzugefügt, woraufhin aDrawing einen Refresh-Request an sich selbst sendet. Beachtenswert ist hier, dass aDrawing im Rahmen der Refresh-Operation auch einen Draw-Request an aLineShape ausgibt.