Objektorientierte Programmierung

Transkript

1 180 INDEX Multimethode, 128, 130, 132 Nachbedingung, 57, 63 Nachricht, 10, 12 Nebenläufigkeit, null, 15 Oberklasse, 20 Obertyp, 18, 44 Objekt, gleiches, 11 identisches, 11 Objektkopplung, 30 Paket, 84 Paradigma, 36 deklaratives, 37 funktionales, 38 imperatives, 36 logikorientiertes, 38 objektorientiertes, 37 prozedurales, 37 Polymorphismus, ad-hoc, 18, 19 enthaltender, 18, 21, 43 parametrischer, siehe Generizität universeller, 18 private, 14, 84 protected, 84 Prototype, Proxy, public, 14, 84 Refaktorisierung, 31 Schnittstelle, 12, 18, 22, 44 stabile, 50, 52 Schranke, 100 schrittweise Verfeinerung, 27 Server, 56, 61 Simulation, 25, 31 Singleton, subtyping, siehe enthaltender Polymorphismus super, 21, 78, 82 Synchronisation, Template Method, 74, this, 21, 77 Typ, 17, 18, 21, 44, 60 deklarierter, 17, 21, 53, 115 dynamischer, 17, 21, 53, 114 stabiler, 50, 52, 60, 69 statischer, 17, 53 Typparameter, 18, 93, 95 gebundener, 100 Typumwandlung, 19, Untertyp, 18, 44 Untertypbeziehung, 43 76, 102 Ausgangsparameter in, 46 Ausnahme in, 137 Durchgangsparameter in, 46 Eingangsparameter in, 46 Ergebnis in, 45, 46 Konstante in, 45, 46 Methode in, 45 Variable in, 45, 47 Zusicherung in, 62 Untertyprelation, siehe Untertypbeziehung Validierung, 26 Verantwortlichkeit, 29, 162 Vererbung, 20 22, 44, 70, 81, 163 Verhalten, 12, Verifikation, 26 Visitor, 133 Vorbedingung, 57, 62 Wartbarkeit, 24, 25, 69, 73 Wartung, 13, 22, 24 Wasserfallmodell, 26 Wiederverwendung, 31, direkte, 72 indirekte, 72 Wrapper, siehe Decorator Zusicherung, 58 Genauigkeit von, 61 Kommentar als, 59, 64 Zustand, 11, 13, 38 Zuverlässigkeit, 23 zyklischer Prozess, computer lang uages Skriptum zu Objektorientierte Programmierung Wintersemester 2008/2009 Franz Puntigam Technische Universität Wien Institut für Computersprachen

2 2 Index Überladen, 19, 48, 77, 82, 127, 128 Überschreiben, 20, 48, 82 abstrakter Datentyp, 39 Analyse, 26 Array, 15, 78, 102 Ausnahme, Basisklasse, siehe Oberklasse Binden dynamisches, 19, 21, 53, 127, 132 statisches, 19 black box, 13 Brauchbarkeit, 22 Client, 56, 61 data hiding, 13 Datenabstraktion, 13 Decorator, , 168 Einfachvererbung, 21, 50, 81 Entwurf, 26 Entwurfsmuster, 34 36, Ersetzbarkeitsprinzip, 18, Erweiterung, 20 Factory Method, 34, Faktorisierung, 24 Generizität, 18, 41, , 122 gebundene, heterogene, 110 homogene, 110, hook, 154, 173 Identität, 11, 13 implementieren, 12 Implementierung, 12, 26 Instanz, 13 Instanzvariable, 13, 78 Interface, 22, 88 generisches, 95 Invariante, 58, 63 Invarianz, 47 Iterator, 96, Kapselung, 11, 25 Klasse, 13 16, 21, 76 abgeleitete, siehe Unterklasse abstrakte, 67, 79, 88 generische, 95 geschachtelte, 80 innere, 80, 97 konkrete, 68 spezifischste, 13 Klassenvariable, 78 Klassenzusammenhalt, 29 Komponente, 40 Konstante, 45, 79 Konstruktor, 13, 15, 77, 82 Kontravarianz, 47 Kopie, 11, 155, 158 Kovarianz, 46 Lokalität, 24, 51 Mehrfachvererbung, 22, 50, 88 Methode, 12, 79 abstrakte, 68, 79 binäre, 48, 126 generische, 98 statische, 16, 79 Modul, 39,

3 178 LITERATURVERZEICHNIS [13] Sonya E. Keene. Object-Oriented Programming in Common Lisp: A Programmer s Guide to CLOS. Addison-Wesley, Reading, MA, [14] B.B. Kristensen, O.L. Madsen, B. Moller-Pedersen, and K. Nygaard. The BE- TA Programming Language. In Bruce Shriver and Peter Wegner (Eds.): Research Directions in Object-Oriented Programming. MIT Press, [15] Wilf LaLonde and John Pugh. Subclassing Subtyping Is-a. Journal of Object- Oriented Programming, 3(5):57 62, Inhaltsverzeichnis [16] Doug Lea. Concurrent Programming in Java: Design Principles and Patterns. Addison-Wesley, ISBN , [17] Barbara Liskov and Jeannette M. Wing. Specifications and their Use in Defining Subtypes. ACM SIGPLAN Notices, 28(10):16 28, October 1993, Proceedings OOPSLA 93. [18] Satoshi Matsuoka and Akinori Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In Research Directions in Concurrent Object-Oriented Programming, MIT Press, [19] Bertrand Meyer. Eiffel: The Language. Prentice Hall, [20] Bertrand Meyer. Object-Oriented Software Construction, Second Edition. Prentice Hall, [21] Greg Nelson. Systems Programming with Modula-3. Prentice Hall Series in Innovative Technology, ISBN , [22] S.T. Taft and R.A. Duff. Ada 95 Reference Manual. Springer LNCS 1246, [23] David Ungar and Randall B. Smith. Self: The Power of Simplicity. In OOPSLA 87 Conference Proceedings, , Orlando, FL, October, [24] Peter Wegner. Concepts and Paradigms of Object-Oriented Programming. OOPS Messenger, 1(1):7 87, August [25] Peter Wegner and Stanley B. Zdonik. Inheritance as an Incremental Modification Mechanism or What Like is and isn t Like. In S. Gjessing and K. Nygaard (Eds.): Proceedings ECOOP 1988, Springer LNCS 322, 55 77, Grundlagen und Ziele Konzepte objektorientierter Programmierung Objekte Klassen Polymorphismus Vererbung Qualität in der Programmierung Qualität von Programmen Effizienz der Programmerstellung und Wartung Rezept für gute Programme Zusammenhalt und Kopplung Wiederverwendung Entwurfsmuster Paradigmen der Programmierung Imperative Programmierung Deklarative Programmierung Paradigmen für Modularisierungseinheiten Wiederholungsfragen Enthaltender Polymorphismus und Vererbung Das Ersetzbarkeitsprinzip Untertypen und Schnittstellen Untertypen und Codewiederverwendung Dynamisches Binden Ersetzbarkeit und Objektverhalten Client-Server-Beziehungen Untertypen und Verhalten Abstrakte Klassen

4 4 INHALTSVERZEICHNIS 2.3 Vererbung versus Ersetzbarkeit Reale Welt versus Vererbung versus Ersetzbarkeit Vererbung und Codewiederverwendung Exkurs: Klassen und Vererbung in Java Klassen in Java Vererbung in Java Zugriffskontrolle in Java Interfaces in Java Wiederholungsfragen Generizität und Ad-hoc-Polymorphismus Generizität Wozu Generizität? Einfache Generizität in Java Gebundene Generizität in Java Verwendung von Generizität im Allgemeinen Richtlinien für die Verwendung von Generizität Arten der Generizität Typabfragen und Typumwandlungen Verwendung dynamischer Typinformation Typumwandlungen und Generizität Kovariante Probleme Überladen versus Multimethoden Unterschiede zwischen Überladen und Multimethoden Simulation von Multimethoden Ausnahmebehandlung Ausnahmebehandlung in Java Einsatz von Ausnahmebehandlungen Nebenläufige Programmierung Wiederholungsfragen Softwareentwurfsmuster Erzeugende Entwurfsmuster Factory Method Prototype Singleton Strukturelle Entwurfsmuster Decorator Proxy Literaturverzeichnis [1] Martin Abadi and Luca Cardelli. A Theory of Objects. Springer, [2] John Barnes. Ada 95 Rationale. Springer LNCS 1247, [3] Grady Booch. Object-Oriented Analysis and Design with Applications. Second edition, Benjamin-Cummings, Redwood City, California, [4] P. Brinch Hansen. The programming language Concurrent Pascal. IEEE Transactions on Software Engineering, 1(2): , June [5] P. Canning, W. Cook, W. Hill, W. Olthoff, and J. C. Mitchell. F-bounded Polymorphism for Object-Oriented Programming. In Proc. Conf. on Functional Programming Languages and Computer Architecture, , [6] Luca Cardelli and Peter Wegner. On Understanding Types, Data Abstraction, and Polymorphism. ACM Computing Surveys, 17(4): , [7] Craig Chambers. Object-Oriented Multi-Methods in Cecil. In Proceedings of the 6th European Conference on Object-Oriented Programming (ECOOP 92), Springer LNCS 615, Utrecht, The Netherlands, June [8] E. Gamma, R. Helm, R. Johnson and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Massachusetts, [9] E. Gamma, R. Helm, R. Johnson and J. Vlissides. Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley, Bonn, [10] Carlo Ghezzi and Mehdi Jazayeri. Programming Language Concepts. Third edition, Wiley & Sons, New York, [11] Adele Goldberg and David Robson. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, [12] Atsushi Igarashi and Benjamin C. Pierce. Foundations for Virtual Types. In Proceedings of the Thirteenth European Conference on Object-Oriented Programming (ECOOP 99), Springer LNCS 1628, , Lisbon, Portugal, June

5 176 KAPITEL 4. SOFTWAREENTWURFSMUSTER INHALTSVERZEICHNIS Entwurfsmuster für Verhalten Iterator Template Method Wiederholungsfragen

6 6 INHALTSVERZEICHNIS 4.4. WIEDERHOLUNGSFRAGEN Welche Unterschiede gibt es zwischen Decorator und Proxy? 6. Welche Probleme kann es beim Erzeugen von Kopien im Prototype geben? Was unterscheidet flache Kopien von tiefen? 7. Für welche Arten von Problemen ist Decorator gut geeignet, für welche weniger? (Oberfläche versus Inhalt) 8. Kann man mehrere Decorators bzw. Proxies hintereinander verketten? Wozu kann so etwas gut sein? 9. Was unterscheidet hooks von abstrakten Methoden? 10. Welche Arten von Iteratoren gibt es, und wofür sind sie geeignet? 11. Inwiefern können geschachtelte Klassen bei der Implementierung von Iteratoren hilfreich sein? 12. Was ist ein robuster Iterator? Wozu braucht man Robustheit? 13. Wo liegen die Probleme in der Implementierung eines so einfachen Entwurfsmusters wie Singleton?

7 174 KAPITEL 4. SOFTWAREENTWURFSMUSTER Die primitiven Operationen, die von der Template Methode aufgerufen werden, sind in der Regel protected Methoden, damit sie nicht in unerwünschten Zusammenhängen aufrufbar sind. Primitive Operationen, die überschrieben werden müssen, sind als abstract deklariert. Die Template Methode selbst, also die Methode, die den Algorithmus implementiert, soll nicht überschrieben werden. Sie kann als final deklariert sein. Ein Ziel bei der Entwicklung einer Template Methode sollte sein, die Anzahl der primitiven Operationen möglichst klein zu halten. Je mehr Operationen überschrieben werden müssen, desto komplizierter wird die direkte Wiederverwendung von AbstractClass. 4.4 Wiederholungsfragen 1. Erklären Sie folgende Entwurfsmuster und beschreiben Sie jeweils das Anwendungsgebiet, die Struktur, die Eigenschaften und wichtige Details der Implementierung: Factory Method Prototype Singleton Decorator Proxy Iterator Template Method Visitor (siehe Abschnitt 3.4.2) 2. Wird die Anzahl der benötigten Klassen im System bei Verwendung von Factory Method, Prototype, Docorator und Proxy (genüber einem System, das keine Entwurfsmuster verwendet) eher erhöht, vermindert oder bleibt sie unverändert? 3. Wird die Anzahl der benötigten Objekte im System bei Verwendung von Factory Method, Prototype, Docorator und Proxy (genüber einem System, das keine Entwurfsmuster verwendet) eher erhöht, vermindert oder bleibt sie unverändert? 4. Vergleichen Sie Factory Method mit Prototype. Wann stellt welches Entwurfsmuster die bessere Lösung dar? Warum? Vorwort Objektorientierte Programmierung ist eine Vorlesung mit Laborübung im Umfang von zwei Semesterwochenstunden an der TU Wien. Unter anderem werden folgende Themenbereiche der objektorientierten Programmierung an Hand von Java behandelt: Datenabstraktion, Klassenhierarchien, Polymorphismus Objektschnittstellen und Zusicherungen (Schwerpunkt) Vererbung und Untertyprelationen (Schwerpunkt) Generizität (Schwerpunkt) Ausnahmebehandlung, nebenläufige Programmierung Implementierung einiger gängiger Entwurfsmuster TeilnehmerInnen an der Lehrveranstaltung sollen einen Überblick über die wichtigsten Konzepte objektorientierter Programmierung bekommen und diese Konzepte so einzusetzen lernen, dass qualitativ hochwertige und gut wartbare Software entsteht. Subtyping (auf der Basis von Objektschnittstellen mit Zusicherungen) und Generizität bilden Schwerpunkte, die am Ende der Lehrveranstaltung jedenfalls beherrscht werden müssen. Praktische Programmiererfahrung in einer beliebigen Programmiersprache wird vorausgesetzt. Java-Vorkenntnisse werden dringend empfohlen. Das Erlernen von Java im Selbststudium neben der Lehrveranstaltung ist möglich. Das erste Kapitel dieses Skriptums führt grundlegende objektorientierte Programmierkonzepte ein, gibt einen Überblick über Qualität in der Programmierung, weist darauf hin, mit welchen Problemen man in der objektorientierten Programmierung rechnen muss und wie man diese lösen kann, 7

8 8 VORWORT und klassifiziert Programmiersprachen anhand ihrer Paradigmen, um eine Einordnung der objektorientierten Sprachen in die Vielfalt an Programmiersprachen zu erleichtern. Das zweite Kapitel beschäftigt sich mit dem besonders wichtigen Themenkomplex des enthaltenden Polymorphismus zusammen mit Klassenhierarchien, Untertypbeziehungen und Vererbung. Vor allem das Ersetzbarkeitsprinzip und Zusicherungen (Design by Contract) werden ausführlich behandelt. Eine Beschreibung der Umsetzung entsprechender Konzepte in Java rundet das zweite Kapitel ab. Das dritte Kapitel ist neben weiteren Formen des Polymorphismus vor allem der Generizität gewidmet. Es werden Programmiertechniken vorgestellt, die entsprechende Problemstellungen auch bei fehlender Sprachunterstützung für Generizität, kovariante Spezialisierungen und mehrfaches dynamisches Binden lösen können. Auch Ausnahmebehandlung und nebenläufige Programmierung werden im dritten Kapitel kurz angesprochen. Das letzte Kapitel stellt eine Auswahl an häufig verwendeten Entwurfsmustern vor. Nebenbei werden praktische Tipps und Tricks in der objektorientierten Programmierung gegeben. Die Lehrveranstaltung soll einen Überblick über Konzepte der objektorientierten Programmierung, Zusammenhänge zwischen ihnen, mögliche Schwierigkeiten sowie Ansätze zu deren Beseitigung vermitteln. Keinesfalls soll sie als Java-Kurs verstanden werden. Insbesondere die umfangreichen Klassenbibliotheken, die in der Java-Programmierung Verwendung finden, werden nicht behandelt. Informationen zu Java gibt es unter anderem im world wide web, zum Beispiel unter Ebenso zu Sprachen wie C# und C++ findet man im world wide web zahlreiche Resourcen. Eine umfangreiche Sammlung von Verweisen auf für die objektorientierte Programmierung relevante Seiten befindet sich unter Viel Erfolg bei der Teilnahme an der Lehrveranstaltung! Franz Puntigam ENTWURFSMUSTER FÜR VERHALTEN 173 Die (meist abstrakte) Klasse AbstractClass definiert (abstrakte) primitive Operationen, welche konkrete Unterklassen als Schritte in einem Algorithmus implementieren, und implementiert das Grundgerüst des Algorithmus, das die primitiven Operationen aufruft. Die Klasse Concrete- Class implementiert die primitiven Operationen. Template Methods haben unter anderem folgende Eigenschaften: Sie stellen eine fundamentale Technik zur direkten Wiederverwendung von Programmcode dar (siehe Beispiele in Abschnitt 2.3.2). Sie sind vor allem in Klassenbibliotheken sinnvoll, weil sie ein Mittel sind, um gemeinsames Verhalten zu faktorisieren. Sie führen zu einer umgekehrten Kontrollstruktur, die manchmal als Hollywood-Prinzip bezeichnet wird ( Don t call us, we ll call you ). Die Oberklasse ruft die Methoden der Unterklasse auf nicht umgekehrt. Sie rufen oft nur eine von mehreren Arten von Operationen auf: konkrete Operationen (entweder in ConcreteClass oder in der Klasse, in der die Template Methods angewandt werden); konkrete Operationen in AbstractClass, also Operationen, die ganz allgemein auch für Unterklassen sinnvoll sind; abstrakte primitive Operationen, die einzelne Schritte im Algorithmus ausführen; Factory Methods; hooks, das sind Operationen mit in AbstractClass definiertem Default-Verhalten, das bei Bedarf in Unterklassen überschrieben oder erweitert werden kann; oft besteht das Default-Verhalten darin, nichts zu tun. Es ist wichtig, dass genau spezifiziert ist, welche Operationen hooks (dürfen überschrieben werden) und welche abstrakt sind (müssen überschrieben werden). Für die effektive Wiederverwendung ist es wichtig, dass die SchreiberInnen von Unterklassen wissen, welche Operationen dafür vorgesehen sind, überschrieben zu werden. Alle Operationen, bei denen es Sinn macht, dass sie in Unterklassen überschrieben werden, sollen hooks sein, da es beim Überschreiben anderer Operationen leicht zu Fehlern kommt.

9 172 KAPITEL 4. SOFTWAREENTWURFSMUSTER man die Schleife nur so lange auszuführen, so lange es Elemente gibt bei leeren Aggregaten daher nie ohne eine eigene Behandlung für den Spezialfall zu brauchen Template Method Eine Template Method definiert das Grundgerüst eines Algorithmus in einer Operation, überlässt die Implementierung einiger Schritte aber einer Unterklasse. Template Methods erlauben einer Unterklasse, bestimmte Schritte zu überschreiben, ohne die Struktur des Algorithmus zu ändern. Dieses Entwurfsmuster ist anwendbar um den unveränderlichen Teil eines Algorithmus einmal zu implementieren und es Unterklassen zu überlassen, den veränderbaren Teil des Verhaltens festzulegen; wenn gemeinsames Verhalten mehrerer Unterklassen (zum Beispiel im Zuge einer Refaktorisierung) in einer einzigen Klasse lokal zusammengefasst werden soll, um Duplikate im Code zu vermeiden; um mögliche Erweiterungen in Unterklassen zu kontrollieren, beispielsweise durch Template Methods, die hooks aufrufen und nur das Überschreiben dieser hooks in Unterklassen ermöglichen. Die Struktur dieses Entwurfsmusters ist recht einfach: AbstractClass templatemethod() primitiveoperation1() primitiveoperation2() ConcreteClass primitiveoperation1() primitiveoperation2() Kapitel 1 Grundlagen und Ziele Immer mehr Unternehmen der Softwarebranche steigen auf objektorientierte Programmierung um. Ein großer Teil der SoftwareentwicklerInnen verwendet derzeit bereits Methoden der objektorientierten Programmierung. Dabei stellt sich die Frage, welche Vorteile die objektorientierte Programmierung gegenüber anderen Paradigmen bietet oder zumindest erwarten lässt, die den umfangreichen Einsatz in der Praxis rechtfertigen. Solche erhofften Vorteile sowie mögliche Gefahren wollen wir in diesem Kapitel betrachten. Die Stellung der objektorientierten Programmierung unter der Vielzahl existierender Programmierparadigmen wollen wir durch eine Klassifizierung der Paradigmen veranschaulichen. Außerdem soll das Kapitel einen ersten Überblick über objektorientierte Programmiersprachkonzepte sowie die später im Detail behandelten Themen geben und nebenbei einige häufig verwendete Begriffe einführen. In Abschnitt 1.1 werden die wichtigsten Konzepte objektorientierter Programmiersprachen angesprochen. Viele dieser Konzepte werden in den folgenden Kapiteln genauer behandelt. In Abschnitt 1.2 beschäftigen wir uns damit, welche Ziele durch die Programmierung im Allgemeinen erreicht werden sollen und was gute Programmierung von schlechter unterscheidet. In Abschnitt 1.3 werden wir untersuchen, wie man gute objektorientierte Programme erkennt bzw. schreibt und welche Schwierigkeiten dabei zu überwinden sind. Abschnitt 1.4 gibt eine Klassifizierung von Programmiersprachen anhand ihrer üblichen Verwendungen. Diese Klassifizierung soll Zusammenhänge mit anderen Paradigmen aufzeigen und helfen, den Begriff der objektorientierten Programmierung abzugrenzen. 9

10 10 KAPITEL 1. GRUNDLAGEN UND ZIELE 1.1 Konzepte objektorientierter Programmierung Wir wollen zunächst einige Grundkonzepte betrachten. Die objektorientierte Programmierung will vor allem Softwareentwicklungsprozesse, die auf inkrementelle Verfeinerung aufbauen, unterstützen. Gerade bei diesen Entwicklungsprozessen spielt die leichte Wartbarkeit der Programme eine große Rolle. Im Wesentlichen will die objektorientierte Programmierung auf die einfache Änderbarkeit von Programmen achten, und objektorientierte Programmiersprachen geben EntwicklerInnen Werkzeuge in die Hand, die sie zum Schreiben leicht wartbarer Software brauchen Objekte Das wichtigste Konzept der objektorientierten Programmierung ist, wie der Name schon sagt, das des Objekts. Ein Objekt ist eine grundlegende Einheit in der Ausführung eines Programms. Zur Laufzeit besteht die Software aus einer Menge von Objekten, die einander teilweise kennen und untereinander Nachrichten (messages) austauschen. Man kann ein Objekt am ehesten als Kapsel verstehen, die zusammengehörende Variablen und Routinen (ausführbare Einheiten wie z.b. Funktionen, Prozeduren und Methoden) enthält. Gemeinsam beschreiben die Variablen und Routinen eine Einheit in der Software. Von außen soll man auf das Objekt nur zugreifen, indem man ihm eine Nachricht schickt, das heißt, eine nach außen sichtbare Routine des Objekts aufruft. Die folgende Abbildung veranschaulicht ein Objekt: Objekt: einstack nicht öffentliche (private) Variablen: elems: "a" "b" "c" null null size: 3 öffentlich aufrufbare Routinen: push: pop: Implementierung der Routine Implementierung der Routine Dieses Objekt mit der Funktionalität eines Stacks fügt zwei Variablen und zwei Routinen zu einer Einheit zusammen und grenzt die Einheit so weit 4.3. ENTWURFSMUSTER FÜR VERHALTEN 171 Oft ist es schwierig, externe Iteratoren auf Sammlungen von Elementen zu verwenden, wenn diese Elemente zueinander in komplexen Beziehungen stehen. Durch die sequentielle Abarbeitung geht die Struktur dieser Beziehungen verloren. Beispielsweise erkennt man an einem vom Iterator zurückgegebenen Element nicht mehr, an welcher Stelle in einem Baum das Element steht. Wenn die Beziehungen zwischen den Elementen bei der Abarbeitung benötigt werden, ist es meist einfacher, interne statt externer Iteratoren zu verwenden. Beispielsweise können wir die Methode max in CollectionOps2 (siehe Abschnitt 3.1.3) als internen Iterator betrachten, der eine durch das Argument spezifizierte Methode in diesem Fall einen Vergleich auf die Elemente des Aggregats anwendet. Der Algorithmus zum Durchwandern eines Aggregats muss nicht immer im Iterator selbst definiert sein. Auch das Aggregat kann den Algorithmus bereitstellen und den Iterator nur dazu benützen, eine Referenz auf das nächste Element zu speichern. Wenn der Iterator den Algorithmus definiert, ist es leichter, mehrere Iteratoren mit unterschiedlichen Algorithmen zu verwenden. In diesem Fall ist es auch leichter, Teile eines Algorithmus in einem anderen Algorithmus wiederzuverwenden. Andererseits müssen die Algorithmen oft private Implementierungsdetails des Aggregats verwenden. Das geht natürlich leichter, wenn die Algorithmen im Aggregat definiert sind. In Java kann man Iteratoren durch geschachtelte Klassen in Aggregaten definieren, wie zum Beispiel den Iterator in der Klasse List (siehe Abschnitt 3.3.2). Dadurch wird die ohnehin schon starke Abhängigkeit zwischen Aggregat und Iterator aber leider noch stärker. Es kann gefährlich sein, ein Aggregat zu verändern, während es von einem Iterator durchwandert wird. Wenn Elemente dazugefügt oder entfernt werden, passiert es leicht, dass Elemente nicht oder doppelt abgearbeitet werden. Eine einfache Lösung dieses Problems besteht darin, das Aggregat bei der Erzeugung eines Iterators zu kopieren. Meist ist diese Lösung aber zu aufwändig. Ein robuster Iterator erreicht dasselbe Ziel, ohne das ganze Aggregat zu kopieren. Es ist recht aufwändig, robuste Iteratoren zu schreiben. Die Detailprobleme hängen stark von der Art des Aggregats ab. Aus Gründen der Allgemeinheit ist es oft praktisch, Iteratoren auch auf leeren Aggregaten bereitzustellen. In einer Anwendung braucht

11 170 KAPITEL 4. SOFTWAREENTWURFSMUSTER Es gibt zahlreiche Möglichkeiten zur Implementierung von Iteratoren. Beispiele dafür haben wir bereits gesehen. Hier sind einige Anmerkungen zu Implementierungsvarianten: Man kann zwischen internen und externen Iteratoren unterscheiden. Interne Iteratoren kontrollieren selbst, wann die nächste Iteration erfolgt, bei externen Iteratoren bestimmen die Anwender, wann sie das nächste Element abarbeiten möchten. Alle Beispiele zu Iteratoren, die wir bis jetzt betrachtet haben, sind externe Iteratoren, bei denen Anwender in einer Schleife nach dem jeweils nächsten Element fragen. Ein interner Iterator enthält die Schleife selbst. Der Anwender übergibt dem Iterator eine Routine, die vom Iterator auf allen Elementen ausgeführt wird. Externe Iteratoren sind flexibler als interne Iteratoren. Zum Beispiel ist es mit externen Iteratoren leicht, zwei Aggregate miteinander zu vergleichen. Mit internen Iteratoren ist das schwierig. Andererseits sind interne Iteratoren oft einfacher zu verwenden, da eine Anwendung die Logik für die Iterationen (also die Schleife) nicht braucht. Interne Iterationen spielen vor allem in der funktionalen Programmierung eine große Rolle, da es dort gute Unterstützung für die dynamische Erzeugung und Übergabe von Routinen (in diesem Fall Funktionen) an Iteratoren gibt, andererseits aber externe Schleifen nur umständlich zu realisieren sind. In der objektorientierten Programmierung werden hauptsächlich externe Iteratoren eingesetzt. Da der Umgang mit externen Iteratoren komplizierter und fehleranfälliger ist als der mit internen Iteratoren, hat Java in der Version 1.5 eine spezielle Syntax für for-schleifen eingeführt, die die Verwendung vereinfacht, wenn die zusätzliche Flexibilität externer Iteratoren nicht gebraucht wird. Mit l vom Typ List<String> ist for (String s : l) s.dosomething(); eine abgekürzte Schreibweise für for (Iterator<String> i=l.iterator(); i.hasnext();) { String s = i.next(); s.dosomething(); 1.1. KONZEPTE OBJEKTORIENTIERTER PROGRAMMIERUNG 11 wie möglich vom Rest des Systems ab. Die beiden öffentlichen Routinen sind von überall aufrufbar. Auf die privaten Variablen kann nur durch die beiden Routinen innerhalb des Objekts zugegriffen werden. Eine Variable enthält ein Array mit dem Inhalt des Stacks, eine andere die aktuelle Anzahl der Elemente am Stack. Das Array kann höchstens fünf Stackelemente halten. Zurzeit sind drei Einträge vorhanden. Das Zusammenfügen von Daten und Routinen zu einer Einheit nennt man Kapselung (encapsulation). Daten und Routinen in einem Objekt sind untrennbar miteinander verbunden: Die Routinen benötigen die Daten zur Erfüllung ihrer Aufgaben, und die genaue Bedeutung der Daten ist oft nur den Routinen des Objekts bekannt. Routinen und Daten stehen zueinander in einer engen logischen Beziehung. In Abschnitt 1.2 werden wir sehen, dass eine gut durchdachte Kapselung ein wichtiges Qualitätsmerkmal ist. In Abschnitt 1.3 werden wir Faustregeln zur Unterstützung der Suche nach geeigneten Kapselungen kennen lernen. In Abschnitt 1.4 werden wir feststellen, dass die Kapselung von Daten und Routinen zu Objekten ein entscheidendes Kriterium zur Abgrenzung der objektorientierten Programmierung von anderen Programmierparadigmen ist. Jedes Objekt besitzt folgende Eigenschaften[24]: Identität (identity): Seine Identität kennzeichnet ein Objekt eindeutig. Sie ist unveränderlich. Über seine Identität kann man das Objekt ansprechen, ihm also eine Nachricht schicken. Vereinfacht kann man sich die Identität als die Adresse des Objekts im Speicher vorstellen. Dies ist aber nur eine Vereinfachung, da die Identität erhalten bleibt, wenn sich die Adresse ändert zum Beispiel beim Verschieben des Objekts bei der garbage collection oder beim Auslagern in eine Datenbank. Jedenfalls gilt: Gleichzeitig durch zwei Namen bezeichnete Objekte sind identisch (identical) wenn sie am selben Speicherplatz liegen, es sich also um nur ein Objekt mit zwei Namen handelt. Zustand (state): Der Zustand setzt sich aus den Werten der Variablen im Objekt zusammen. Er ist in der Regel änderbar. In obigem Beispiel ändert sich der Zustand durch Zuweisungen neuer Werte an die Variablen elems und size. Zwei Objekte sind gleich (equal) wenn sie denselben Zustand und dasselbe Verhalten haben. Objekte können auch gleich sein, wenn sie nicht identisch sind; dann sind sie Kopien voneinander. Zustände gleicher Objekte können sich unabhängig voneinander ändern; die Gleichheit geht dadurch verloren. Identität kann durch Zustandsänderungen nicht verloren gehen.

12 12 KAPITEL 1. GRUNDLAGEN UND ZIELE Verhalten (behavior): Das Verhalten eines Objekts beschreibt, wie sich das Objekt beim Empfang einer Nachricht verhält, das heißt, was das Objekt beim Aufruf einer entsprechenden Routine macht. Routinen, die beim Empfang von Nachrichten ausgeführt werden, nennt man häufig Methoden (methods). Das Verhalten ist von der Nachricht also dem Methodennamen zusammen mit den aktuellen Parametern, auch Argumente der Nachricht genannt, der entsprechenden aufgerufenen Methode und dem Zustand des Objekts abhängig. In obigem Beispiel wird die Methode push beim Empfang der Nachricht push("d") das Argument "d" in den Stack einfügen (falls es noch einen freien Platz gibt), und pop wird beim Empfang von pop() ein Element entfernen (falls eines vorhanden ist) und an den Absender der Nachricht zurückgeben. Unter der Implementierung einer Methode verstehen wir den Programmcode, der festlegt, was genau beim Aufruf der Methode zu tun ist. Die Implementierungen aller Methoden eines Objekts und die Deklarationen der Variablen des Objekts bilden zusammen die Implementierung des Objekts. Die Implementierung beschreibt das Verhalten des Objekts bis ins kleinste Detail. Für die Programmausführung ist diese genaue Beschreibung ganz essentiell; sonst wüsste der Computer nicht, was er tun soll. Aber für die Wartung ist es günstiger, wenn das Verhalten eines Objekts nicht jedes Detail der Implementierung widerspiegelt. Wir fordern (neben obigen drei Eigenschaften, die zur Definition des Begriffs Objekt unbedingt notwendig sind) eine weitere Eigenschaft, die es ermöglicht, den Detailiertheitsgrad des Verhaltens nach Bedarf zu steuern: Schnittstelle (interface): Eine Schnittstelle eines Objekts beschreibt das Verhalten des Objekts in einem Detailiertheitsgrad, der für Zugriffe von außen notwendig ist. Ein Objekt kann mehrere Schnittstellen haben, die das Objekt aus den Sichtweisen unterschiedlicher Verwendungen beschreiben. Oft enthalten Schnittstellen nur die Köpfe der überall aufrufbaren Routinen ohne weitere Beschreibung des Verhaltens. Manchmal enthalten sie auch Konstanten. Wie wir in Kapitel 2 sehen werden, kann man das Verhalten in Schnittstellen (zumindest verbal) beliebig genau beschreiben. Ein Objekt implementiert seine Schnittstellen; das heißt, die Implementierung legt das in den Schnittstellen unvollständig beschriebene Verhalten im Detail fest. Jede Schnittstelle kann das Verhalten beliebig vieler Objekte beschreiben. Schnittstellen entsprechen den Typen des Objekts ENTWURFSMUSTER FÜR VERHALTEN 169 Aggregate iterator() ConcreteAggregate iterator() Iterator next() hasnext() ConcreteIterator next() hasnext() Die abstrakte Klasse oder das Interface Iterator definiert eine Schnittstelle für den Zugriff auf Elemente sowie deren Abarbeitung. Die Klasse ConcreteIterator implementiert diese Schnittstelle und verwaltet die aktuelle Position in der Abarbeitung. Die abstrakte Klasse oder das Interface Aggregate definiert eine Schnittstelle für die Erzeugung eines neuen Iterators. Die Klasse ConcreteAggregate implementiert diese Schnittstelle. Ein Aufruf von iterator erzeugt eine neue Instanz von ConcreteIterator, was durch den strichlierten Pfeil angedeutet ist. Um die aktuel- le Position im Aggregat verwalten zu können, braucht jede Instanz von ConcreteIterator eine Referenz auf die entsprechende Instanz von ConcreteAggregate, angedeutet mittels durchgezogenem Pfeil. Iteratoren haben drei wichtige Eigenschaften: Sie unterstützen unterschiedliche Varianten in der Abarbeitung von Aggregaten. Für komplexe Aggregate wie beispielsweise Bäume gibt es zahlreiche Möglichkeiten, in welcher Reihenfolge die Elemente abgearbeitet werden. Es ist leicht, mehrere Iteratoren für unterschiedliche Abarbeitungsreihenfolgen zu implementieren. Iteratoren vereinfachen die Schnittstelle von Aggregate, da Zugriffsmöglichkeiten, die über Iteratoren bereitgestellt werden, durch die Schnittstelle von Aggregate nicht unterstützt werden müssen. Auf ein und demselben Aggregat können gleichzeitig mehrere Abarbeitungen stattfinden, da jeder Iterator selbst den aktuellen Abarbeitungszustand verwaltet.

13 168 KAPITEL 4. SOFTWAREENTWURFSMUSTER In der Implementierung muss man beachten, wie man auf ein Objekt zeigt, das in einem anderen Namensraum liegt oder noch gar nicht existiert. Für nicht existierende Objekte könnte man zum Beispiel null verwenden und für Objekte in einer Datei den Dateinamen. Ein Proxy kann dieselbe Struktur wie ein Decorator haben. Aber Proxies dienen einem ganz anderen Zweck als Decorators: Ein Decorator erweitert ein Objekt um zusätzliche Verantwortlichkeiten, während ein Proxy den Zugriff auf das Objekt kontrolliert. Damit haben diese Entwurfsmuster auch gänzlich unterschiedliche Eigenschaften. 4.3 Entwurfsmuster für Verhalten Zwei Beispiele zu Entwurfsmustern für Verhalten, nämlich Iterator und Visitor, haben wir bereits in Kapitel 3 beschrieben. Hier wollen wir nur einige ergänzende Bemerkungen zu Iteratoren machen. Ein weiteres Entwurfsmuster, nämlich Template Method soll dazu anregen, beim Entwerfen und Programmieren von Software der eigenen Fantasie freien Lauf zu lassen und auch dort Möglichkeiten für die Wiederverwendung von Programmcode zu finden, wo es keine spezielle Unterstützung durch eine Programmiersprache gibt Iterator Ein Iterator, auch Cursor genannt, ermöglicht den sequentiellen Zugriff auf die Elemente eines Aggregats (das ist eine Sammlung von Elementen, beispielsweise eine Collection), ohne die innere Darstellung des Aggregats offen zu legen. Dieses Entwurfsmuster ist verwendbar um auf den Inhalt eines Aggregats zugreifen zu können, ohne die innere Darstellung offen legen zu müssen; mehrere (gleichzeitige bzw. überlappende) Abarbeitungen der Elemente in einem Aggregat zu ermöglichen; eine einheitliche Schnittstelle für die Abarbeitung verschiedener Aggregatstrukturen zu haben, das heißt, um polymorphe Iterationen zu unterstützen. Das Entwurfsmuster hat folgende Struktur: 1.1. KONZEPTE OBJEKTORIENTIERTER PROGRAMMIERUNG 13 Häufig verwendet man ein Objekt als black box oder grey box; das heißt, der Inhalt des Objekts ist von außen zum Großteil nicht sichtbar. Nur das, was in den Schnittstellen beschrieben ist, ist von außen sichtbar. Schnittstellen dienen dazu, den Inhalt des Objekts von dessen verschiedenen Außenansichten klar zu trennen. ProgrammiererInnen, die ein Objekt verwenden wollen, brauchen nur eine Schnittstelle des Objekts kennen, nicht aber dessen Inhalt. Man spricht daher von data hiding, dem Verstecken von Daten und Implementierungen. Kapselung zusammen mit data hiding heißt Datenabstraktion, da die Daten in einem Objekt nicht mehr direkt sichtbar und manipulierbar, sondern abstrakt sind. Im Beispiel sieht man die Daten des Objekts nicht als Array von Elementen zusammen mit der Anzahl der gültigen Einträge im Array, sondern als abstrakten Stack, der über zwei Methoden zugreifbar und manipulierbar ist. Diese Abstraktion bleibt unverändert, wenn wir das Array gegen eine andere Datenstruktur, sagen wir eine Liste, austauschen. Datenabstraktionen helfen bei der Wartung: Details von Objekten sind änderbar, ohne deren Außenansichten und damit deren Verwendungen zu beeinflussen Klassen Viele objektorientierte Sprachen beinhalten ein Klassenkonzept: Jedes Objekt gehört zu genau einer Klasse, die die Struktur des Objekts dessen Implementierung im Detail beschreibt. Außerdem beschreibt die Klasse Konstruktoren (constructors), das sind Routinen zur Erzeugung und Initialisierung neuer Objekte. Alle Objekte, die zur Klasse gehören, wurden durch Konstruktoren dieser Klasse erzeugt. Man nennt diese Objekte Instanzen der Klasse. Genauer gesagt sind die Objekte Instanzen der durch die Klasse beschriebenen Schnittstellen bzw. Typen. Die Klasse selbst ist die spezifischste aller dieser Schnittstellen, die das Verhalten am genauesten beschreibt. (Anmerkung: Man sagt manchmal, ein Objekt gehöre zu mehreren Klassen, der spezifischsten Klasse und deren Oberklassen; wir verstehen im Skriptum unter der Klasse eines Objekts immer dessen spezifischste Klasse beziehungsweise Schnittstelle und sprechen von der Schnittstelle eines Objekts wenn wir eine beliebige Schnittstelle meinen.) Alle Instanzen einer Klasse haben dieselben Implementierungen und dieselben Schnittstellen. Aber unterschiedliche Instanzen haben immer unterschiedliche Identitäten und unterschiedliche Variablen genauer: Instanzvariablen obwohl diese Variablen gleiche Namen und Typen tragen. Auch die Zustände können sich unterscheiden.

14 14 KAPITEL 1. GRUNDLAGEN UND ZIELE In einer objektorientierten Programmiersprache mit Klassen schreiben ProgrammiererInnen hauptsächlich Klassen. Objekte werden nur zur Laufzeit durch Verwendung von Konstruktoren erzeugt. Oft gibt es in diesen Sprachen gar keine Möglichkeit, Objekte direkt auszuprogrammieren. Ein kleines Beispiel in Java soll demonstrieren, wie Klassen aussehen: class Stack { private String[] elems; private int size = 0; public Stack (int sz) { elems = new String[sz]; public void push (String elem) { if (size < elems.length) { elems[size] = elem; size = size + 1; public String pop() { if (size > 0) { size = size - 1; return elems[size]; else return null; Folgende Beispielerklärung ist für Leser gedacht, die noch nicht genug Erfahrung mit Java gesammelt haben. Erfahrene ProgrammiererInnen in Java können solche speziell gekennzeichneten Textstellen überspringen. (Anmerkungen zu Java) Jede Instanz der Klasse Stack enthält die Variablen elems vom Typ String[] (Array von Zeichenketten) sowiesize vom Typint (ganze Zahl von 2 31 bis ). Alle Variablen sind mit private deklariert, also nur in Instanzen von Stack sichtbar. Jede Instanz unterstützt push und pop. Beide Methoden sind public, also überall sichtbar, wo eine Instanz von Stack bekannt ist. Der Ergebnistyp void bedeutet, dass push kein Ergebnis zurück gibt. Der formale Parameter elem von push ist vom Typ String. Die Methode pop liefert ein Ergebnis vom Typ String, hat aber keine formalen Parameter ausgedrückt durch ein leeres Klammerpaar. Daneben gibt es einen Konstruktor. Syntaktisch sieht ein Konstruktor wie eine Methode aus, abgesehen davon, dass der 4.2. STRUKTURELLE ENTWURFSMUSTER 167 RealSubject request() realsubject Subject request() Proxy request() Die abstrakte Klasse oder das Interface Subject definiert die gemeinsame Schnittstelle für Instanzen von RealSubject und Proxy. Instanzen von RealSubject und Proxy können gleichermaßen verwendet werden, wo eine Instanz von Subject erwartet wird. Die Klasse RealSubject definiert die eigentlichen Objekte, die durch die Proxies (Platzhalter) repräsentiert werden. Die Klasse Proxy definiert schließlich die Proxies. Diese Klasse verwaltet eine Referenz realsubject, über die ein Proxy auf Instanzen von RealSubject (oder auch andere Instanzen von Subject ) zugreifen kann; stellt eine Schnittstelle bereit, die der von Subject entspricht, damit ein Proxy als Ersatz des eigentlichen Objekts verwendet werden kann; kontrolliert Zugriffe auf das eigentliche Objekt und kann für dessen Erzeugung oder Entfernung verantwortlich sein; hat weitere Verantwortlichkeiten, die von der Art abhängen. Es kann mehrere unterschiedliche Klassen für Proxies geben. Zugriffe auf Instanzen von RealSubject können durch mehrere Proxies (möglicherweise unterschiedlicher Typen) kontrolliert werden, die in Form einer Kette miteinander verbunden sind. In obiger Grafik zur Struktur des Entwurfsmusters zeigt ein Pfeil von Proxy auf RealSubject. Das bedeutet, Proxy muss RealSubject kennen. Dies ist notwendig, wenn ein Proxy Instanzen von RealSubject erzeugen soll. In anderen Fällen reicht es, wenn Proxy nur Subject kennt, der Pfeil also auf Subject zeigt.

15 166 KAPITEL 4. SOFTWAREENTWURFSMUSTER richten an das eigentliche Objekt weiter, möglicherweise nachdem weitere Aktionen gesetzt wurden. Einige Nachrichten werden manchmal auch direkt vom Proxy behandelt. Das Entwurfsmuster ist anwendbar, wenn eine intelligentere Referenz auf ein Objekt als ein simpler Zeiger nötig ist. Hier sind einige übliche Situationen, in denen ein Proxy eingesetzt werden kann (keine vollständige Aufzählung): Remote Proxies sind Platzhalter für Objekte, die in anderen Namensräumen (zum Beispiel auf Festplatten oder auf anderen Rechnern) existieren. Nachrichten an die Objekte werden von den Proxies über komplexere Kommunikationskanäle weitergeleitet. Virtual Proxies erzeugen Objekte bei Bedarf. Da die Erzeugung eines Objekts aufwändig sein kann, wird sie so lange verzögert, bis es wirklich einen Bedarf dafür gibt. Protection Proxies kontrollieren Zugriffe auf Objekte. Solche Proxies sind sinnvoll, wenn Objekte je nach Zugreifer oder Situation unterschiedliche Zugriffsrechte haben sollen. Smart References ersetzen einfache Zeiger. Sie können bei Zugriffen zusätzliche Aktionen ausführen. Typische Verwendungen sind das Mitzählen der Referenzen auf das eigentliche Objekt, damit das Objekt entfernt werden kann, wenn es keine Referenz mehr darauf gibt (reference counting); das Laden von persistenten Objekten in den Speicher, wenn das erste Mal darauf zugegriffen wird (wobei die Unterscheidung zu Virtual Proxies manchmal unklar ist); das Zusichern, dass während des Zugriffs auf das Objekt kein gleichzeitiger Zugriff durch einen anderen Thread erfolgt (beispielsweise durch Setzen eines locks ). Es gibt zahlreiche weitere Einsatzmöglichkeiten. Der Phantasie sind hier kaum Grenzen gesetzt. Die Struktur dieses Entwurfsmusters ist recht einfach: 1.1. KONZEPTE OBJEKTORIENTIERTER PROGRAMMIERUNG 15 Name immer gleich dem Namen der Klasse ist und kein Ergebnistyp angegeben wird. Der Konstruktor im Beispiel ist public, also überall sichtbar. Neue Objekte werden durch den Operator new erzeugt und durch den Aufruf eines Konstruktors initialisiert. Zum Beispiel erzeugt new Stack(5) eine neue Instanz von Stack mit neuen Variablen elems und size und ruft den Konstruktor in Stack auf, wobei der formale Parameter sz an 5 gebunden ist. Bei der Ausführung des Konstruktors wird durch new String[sz] eine neue Instanz eines Arrays von Zeichenketten erzeugt. Im Array finden 5 Zeichenketten Platz. Dieses Array wird an die Variable elems zugewiesen. Die Variable size wurde bereits zu Beginn mit 0 initialisiert. In Java sind auch Arrays gewöhnliche Objekte, allerdings mit einer speziellen Syntax durch Verwendung eckiger Klammern. Bei der Objekterzeugung enthalten die eckigen Klammern die Anzahl der Array-Einträge, bei einem Zugriff den Index. Der unterste Index ist immer 0. Am Anfang enthält jeder Array-Eintrag null; das bedeutet, dass der Eintrag mit keinem Objekt belegt ist. Jede Variable in Java, die ein Objekt enthalten kann, kann stattdessen auch null enthalten. Ein Aufruf von push stellt fest, ob es im Array noch einen freien Eintrag gibt, also size kleiner als elems.length (die Größe des Arrays elems) ist. In diesem Fall wird der Parameter als neues Element in das Array eingetragen und size erhöht; andernfalls bleibt der Zustand unverändert. Ein Aufruf von pop verringert size um 1 und liefert durch eine return-anweisung den Array-Eintrag an der Position size zurück, falls size größer als 0 ist. Sonst liefert die Methode null kein Objekt zurück. Da jede Instanz von Stack ihre eigenen Variablen hat, stellt sich die Frage, zu welcher Instanz von Stack die Variablen gehören, auf die die Methoden zugreifen. In der Klasse selbst steht nirgends, welches Objekt das ist. Die Instanz von Stack, die dabei verwendet wird, ist im Aufruf der Methode eindeutig festgelegt, wie wir an folgendem Beispiel sehen: class StackTest { public static void main (String[] args) { Stack s = new Stack(5); int i = 0; while (i < args.length) { s.push(args[i]); i = i + 1; while (i > 0) { i = i - 1; System.out.println(s.pop());

16 16 KAPITEL 1. GRUNDLAGEN UND ZIELE (Anmerkungen zu Java) Die Klasse StackTest definiert nur eine Methode main. Diese Methode wird automatisch aufgerufen, wenn StackTest als Java-Programm verwendet wird. Die Methode ist public und static; das heißt, sie ist überall sichtbar und hängt nicht von irgendwelchen Variablen einer Instanz von StackTest ab. Daher können wir main überall aufrufen, ohne eine Instanz von StackTest zu benötigen. Das ist erforderlich, da es beim Start des Programms ja noch keine Instanzen der Klasse gibt. Die Methode hat ein Array von Zeichenketten als Parameter. Beim Programmstart enthält dieses Array die Argumente (command line arguments), die im Programmaufruf angegeben werden. Nachdem StackTest und Stack durch javac Stack.java StackTest.java übersetzt wurden, können wir das Programm zum Beispiel so aufrufen: java StackTest a b c Damit ist args ein Array von drei Zeichenketten "a", "b" und "c". Die Methode main hat zwei lokale Variablen. Die Variable s wird mit einer neuen Instanz von Stack initialisiert und i mit 0. Die erste Schleife wird für jede Zeichenkette in args einmal durchlaufen. Der Ausdruck args.length bezeichnet die Variable length im Objekt args, die in unserem Fall die Anzahl der Elemente im Array angibt. In jedem Schleifendurchlauf wird die Nachricht push(args[i]) an das Objekt s gesendet; es wird also push in s mit der Zeichenkette args[i] als Argument aufgerufen. Bei der Ausführung von push ist bekannt, dass die Variablen des Objekts s zu verwenden sind. Die zweite Schleife wird gleich oft durchlaufen wie die erste. Die Anweisung System.out.println(s.pop()) gibt das oberste Element am Stack auf die Standardausgabe normalerweise das Terminal aus und entfernt dieses Element vom Stack. Im Detail passiert Folgendes: System ist eine im Java-System vorgegebene Klasse, die eine statische Variable out enthält. Eine mit static deklarierte Variable unterscheidet sich von einer Instanzvariable ohne static deklariert dadurch, dass sie nicht zu einer Instanz der Klasse gehört, sondern zur Klasse selbst. Daher brauchen wir auch keine Instanz von System anzugeben, um auf die Variable zuzugreifen, sondern die Klasse selbst. Die Variable System.out enthält ein Objekt, den output stream für die Standardausgabe. In diesem Objekt wird die Methode println aufgerufen, die eine Zeile mit dem Argument in den output stream schreibt. Als Argument wird der Methode das Ergebnis eines Aufrufs von pop in s übergeben. Nach einem Programmaufruf java StackTest a b c werden am Bildschirm folgende drei Zeilen ausgegeben: c b a Was ausgegeben wird, wenn der Programmaufruf mehr als 5 Argumente enthält, kann sich der Leser selbst überlegen oder ausprobieren STRUKTURELLE ENTWURFSMUSTER 165 Die Klasse oder das Interface Component soll so klein wie möglich gehalten werden. Dies kann dadurch erreicht werden, dass Component wirklich nur die notwendigen Operationen, aber keine Daten definiert. Daten und Implementierungsdetails sollen erst in ConcreteComponent vorkommen. Andernfalls werden Dekoratoren umfangreich und ineffizient. Dekoratoren eignen sich gut dazu, die Oberfläche beziehungsweise das Erscheinungsbild eines Objekts zu erweitern. Sie sind nicht gut für inhaltliche Erweiterungen geeignet. Auch für Objekte, die von Grund auf umfangreich sind, eignen sich Dekoratoren kaum. Für solche Objekte sind andere Entwurfsmuster, beispielsweise Strategy, besser geeignet. Auf diese Entwurfsmuster wollen wir hier aber nicht eingehen Proxy Ein Proxy, auch Surrogate genannt, stellt einen Platzhalter für ein anderes Objekt dar und kontrolliert Zugriffe darauf. Es gibt zahlreiche, sehr unterschiedliche Anwendungsmöglichkeiten für Platzhalterobjekte. Ein Beispiel ist ein Objekt, dessen Erzeugung teuer ist, beispielsweise weil umfangreiche Daten aus dem Internet geladen werden müssen. Man erzeugt das eigentliche Objekt erst, wenn es wirklich gebraucht wird. Statt des eigentlichen Objekts verwendet man in der Zwischenzeit einen Platzhalter, der erst bei Bedarf durch das eigentliche Objekt ersetzt wird. Falls nie auf die Daten zugegriffen wird, erspart man sich den Aufwand der Objekterzeugung: interface Something { void dosomething(); class ExpensiveSomething implements Something { public void dosomething() {... class VirtualSomething implements Something { private ExpensiveSomething real = null; public void dosomething() { if (real == null) real = new ExpensiveSomething(); real.dosomething(); Jedes Platzhalterobjekt enthält im Wesentlichen einen Zeiger auf das eigentliche Objekt (sofern dieses existiert) und leitet in der Regel Nach-