Objektorientierte Programmierung - Amazon S3...7 Inhalt In diesem Kapitel stellen die Autoren sich und dieses Buch vor. Sie erklären, was Objektorientierung im Bereich der Softwareentwicklung

Bernhard Lahres, Gregor Raýman

Objektorientierte ProgrammierungDas umfassende Handbuch

1401.book Seite 1 Donnerstag, 5. März 2009 11:32 11

Auf einen Blick

1 Einleitung ............................................................................ 13

2 Die Basis der Objektorientierung ....................................... 27

3 Die Prinzipien des objektorientierten Entwurfs ................. 39

4 Die Struktur objektorientierter Software ........................... 65

5 Vererbung und Polymorphie ............................................... 155

6 Persistenz ........................................................................... 299

7 Abläufe in einem objektorientierten System ...................... 337

8 Module und Architektur ..................................................... 503

9 Aspekte und Objektorientierung ........................................ 527

10 Objektorientierung am Beispiel: Eine Web-Applikation mit PHP 5 und Ajax ....................... 573

A Verwendete Programmiersprachen .................................... 623

B Literaturverzeichnis ............................................................ 641


7

Inhalt

In diesem Kapitel stellen die Autoren sich und dieses Buch vor. Sie erklären, was Objektorientierung im Bereich der Softwareentwicklung bedeutet. Und am Ende des Kapitels geraten sie auch schon in die erste Diskussion miteinander. 13

1 Einleitung ................................................................................... 13

1.1 Was ist Objektorientierung? ......................................................... 131.2 Hallo liebe Zielgruppe ................................................................... 141.3 Was bietet dieses Buch (und was nicht)? ....................................... 15

1.3.1 Bausteine des Buchs ....................................................... 161.3.2 Crosscutting Concerns: übergreifende Anliegen............... 191.3.3 Die Rolle von Programmiersprachen .............................. 20

1.4 Warum überhaupt Objektorientierung? ........................................ 221.4.1 Gute Software: Was ist das eigentlich? ........................... 231.4.2 Die Rolle von Prinzipien ................................................. 241.4.3 Viele mögliche Lösungen für ein Problem ....................... 25

In diesem Kapitel werfen wir vorab bereits einen Blick auf die technischen Möglichkeiten, die uns die Objektorientierung bietet. Und wir stellen die Basiskonzepte Datenkapselung, Vererbung und Polymorphie kurz vor, ohne bereits ins Detail zu gehen. 27

2 Die Basis der Objektorientierung .............................................. 27

2.1 Die strukturierte Programmierung als Vorläufer der Objektorientierung ................................................................. 28

2.2 Die Kapselung von Daten ............................................................. 312.3 Polymorphie ................................................................................. 322.4 Die Vererbung .............................................................................. 34

2.4.1 Vererbung der Spezifikation ........................................... 342.4.2 Erben von Umsetzungen (Implementierungen)................ 35

Prinzipien helfen uns, das Richtige zu tun. Dies gilt in der Softwareentwicklung genauso wie in unserem täglichen Leben. Wir müssen uns allerdings auch vor Prinzipienreiterei hüten und hin und wieder ein Prinzip beiseite legen können. In diesem Kapitel beschreiben wir die grundlegenden Prinzipien, die einem guten objektorientierten Softwareentwurf zugrunde liegen und warumihre Einhaltung meistens eine gute Idee ist. 39

3 Die Prinzipien des objektorientierten Entwurfs ........................ 39

3.1 Prinzip 1: Prinzip einer einzigen Verantwortung ............................ 403.2 Prinzip 2: Trennung der Anliegen ................................................. 453.3 Prinzip 3: Wiederholungen vermeiden ......................................... 473.4 Prinzip 4: Offen für Erweiterung, geschlossen für Änderung ......... 503.5 Prinzip 5: Trennung der Schnittstelle von der Implementierung .... 533.6 Prinzip 6: Umkehr der Abhängigkeiten ......................................... 56

3.6.1 Umkehrung des Kontrollflusses ............................ 603.7 Prinzip 7: Mach es testbar ............................................................ 62

In diesem Kapitel beschreiben wir die grundlegende Struktur von objektorientierten Softwaresystemen. Wir beginnen dabei mit dem Grundlegenden: mit dem Objekt an sich. Danach gehen wir auf die Klassifizierung von Objekten ein und werden uns dann detailliert mit den Klassen und den Beziehungen zwischen Objekten beschäftigen. 65

4 Die Struktur objektorientierter Software .................................. 65

4.1 Die Basis von allem: das Objekt .................................................... 654.1.1 Eigenschaften von Objekten: Objekte als Datenkapseln 67


Inhalt

8

4.1.2 Operationen und Methoden von Objekten .................... 744.1.3 Kontrakte: Ein Objekt trägt Verantwortung .................... 794.1.4 Die Identität von Objekten ............................................ 814.1.5 Objekte haben Beziehungen .......................................... 83

4.2 Klassen: Objekte haben Gemeinsamkeiten .................................... 844.2.1 Klassen sind Modellierungsmittel ................................... 844.2.2 Kontrakte: die Spezifikation einer Klasse ........................ 884.2.3 Klassen sind Datentypen ................................................ 924.2.4 Klassen sind Module ...................................................... 1024.2.5 Sichtbarkeit von Daten und Methoden ........................... 1054.2.6 Klassenbezogene Methoden und Attribute ..................... 1124.2.7 Singleton-Methoden: Methoden für einzelne Objekte..... 116

4.3 Beziehungen zwischen Objekten ................................................... 1174.3.1 Rollen und Richtung einer Assoziation ........................... 1194.3.2 Navigierbarkeit .............................................................. 1204.3.3 Multiplizität .................................................................. 1204.3.4 Qualifikatoren ................................................................ 1254.3.5 Beziehungsklassen, Attribute einer Beziehung ................. 1264.3.6 Implementierung von Beziehungen ................................ 1284.3.7 Komposition und Aggregation ........................................ 1294.3.8 Attribute ........................................................................ 1324.3.9 Beziehungen zwischen Objekten in der Übersicht ........... 133

4.4 Klassen von Werten und Klassen von Objekten ............................ 1334.4.1 Werte in den objektorientierten Programmiersprachen ... 1344.4.2 Entwurfsmuster »Fliegengewicht« ................................... 1374.4.3 Aufzählungen (Enumerations) ........................................ 1404.4.4 Identität von Objekten ................................................... 147

In diesem Kapitel erfahren Sie, wie Sie die Vererbung der Spezifikation im Zusammenspiel mit der Fähigkeit der dynamischen Polymorphie nutzen können, um Ihre Programme flexibler zu gestalten. Wir stellen zunächst Vererbung und Polymorphie vor, um dann an konkreten Aufgabenstellungen deren Möglichkeiten und Grenzen aufzuzeigen. 155

5 Vererbung und Polymorphie ...................................................... 155

5.1 Die Vererbung der Spezifikation ................................................... 1555.1.1 Hierarchien von Klassen und Unterklassen ..................... 1555.1.2 Unterklassen erben die Spezifikation von Oberklassen..... 1575.1.3 Das Prinzip der Ersetzbarkeit ......................................... 1615.1.4 Abstrakte Klassen, konkrete Klassen und

Schnittstellen-Klassen .................................................... 1675.1.5 Vererbung der Spezifikation und das Typsystem.............. 1765.1.6 Sichtbarkeit im Rahmen der Vererbung .......................... 183

5.2 Polymorphie und ihre Anwendungen ............................................ 1935.2.1 Dynamische Polymorphie am Beispiel ............................ 1955.2.2 Methoden als Implementierung von Operationen ........... 200


Inhalt

9

5.2.3 Anonyme Klassen ........................................................... 2085.2.4 Single und Multiple Dispatch ......................................... 2105.2.5 Die Tabelle für virtuelle Methoden ................................. 228

5.3 Die Vererbung der Implementierung ............................................. 2395.3.1 Überschreiben von Methoden ........................................ 2415.3.2 Das Problem der instabilen Basisklassen ......................... 2495.3.3 Problem der Gleichheitsprüfung bei geerbter

Implementierung ........................................................... 2545.4 Mehrfachvererbung ...................................................................... 261

5.4.1 Mehrfachvererbung: Möglichkeiten und Probleme.......... 2615.4.2 Delegation statt Mehrfachvererbung .............................. 2685.4.3 Mixin-Module statt Mehrfachvererbung ......................... 2715.4.4 Die Problemstellungen der Mehrfachvererbung............... 273

5.5 Statische und dynamische Klassifizierung ...................................... 2895.5.1 Dynamische Änderung der Klassenzugehörigkeit............. 2905.5.2 Entwurfsmuster »Strategie« statt dynamischer

Klassifizierung ................................................................ 294

In diesem Kapitel erhalten Sie einen Überblick über die in der Praxis relevanteste Art, Objekte zu speichern und auf die gespeicherten Daten wieder zuzugreifen: die relationalen Datenbanken. Wir beschreiben, wie Sie die Struktur Ihrer Klassen auf relationale Datenbanken abbilden können und wie sich diese Abbildung mit den Regeln für gutes Datenbankdesign ergänzt. 299

6 Persistenz ................................................................................... 299

6.1 Serialisierung von Objekten .......................................................... 2996.2 Speicherung in Datenbanken ........................................................ 300

6.2.1 Relationale Datenbanken ............................................... 3006.2.2 Struktur der relationalen Datenbanken ........................... 3016.2.3 Begriffsdefinitionen ........................................................ 302

6.3 Abbildung auf relationale Datenbanken ........................................ 3076.3.1 Abbildung von Objekten in relationalen Datenbanken .... 3076.3.2 Abbildung von Beziehungen in relationalen

Datenbanken ................................................................. 3116.3.3 Abbildung von Vererbungsbeziehungen auf eine

relationale Datenbank .................................................... 3156.4 Normalisierung und Denormalisierung .......................................... 320

6.4.1 Die erste Normalform: Es werden einzelne Fakten gespeichert .................................................................... 322

6.4.2 Die zweite Normalform: Alles hängt vom ganzen Schlüssel ab ................................................................... 323

6.4.3 Die dritte Normalform: Keine Abhängigkeiten unter den Nichtschlüssel-Spalten ............................................. 326

6.4.4 Die vierte Normalform: Trennen unabhängiger Relationen ..................................................................... 330

6.4.5 Die fünfte Normalform: Einfacher geht’s nicht................. 332


Inhalt

10

In diesem Kapitel beschäftigen wir uns mit dem Verhalten von Objekten zur Laufzeit eines Programms. Wir begleiten Objekte vom Zeitpunkt ihrer Erzeugung über ihre hoffentlich sinnvollen Interaktionen bis zum Ende ihres Lebens, an dem sie oft nur als ein Stück Abfall angesehen werden und von der »Müllabfuhr« (der Garbage Collection) aufgesammelt werden. 337

7 Abläufe in einem objektorientierten System............................. 337

7.1 Erzeugung von Objekten mit Konstruktoren und Prototypen ........ 3387.1.1 Konstruktoren: Klassen als Vorlagen für ihre

Exemplare ...................................................................... 3387.1.2 Prototypen als Vorlagen für Objekte .............................. 3427.1.3 Entwurfsmuster »Prototyp« ............................................ 348

7.2 Fabriken als Abstraktionsebene für die Objekterzeugung .............. 3497.2.1 Statische Fabriken .......................................................... 3527.2.2 Abstrakte Fabriken ......................................................... 3557.2.3 Konfigurierbare Fabriken ................................................ 3607.2.4 Registraturen für Objekte ............................................... 3647.2.5 Fabrikmethoden ............................................................. 3687.2.6 Erzeugung von Objekten als Singletons .......................... 3777.2.7 Dependency Injection .................................................... 386

7.3 Objekte löschen ............................................................................ 3977.3.1 Speicherbereiche für Objekte ......................................... 3977.3.2 Was ist eine Garbage Collection? ................................... 3997.3.3 Umsetzung einer Garbage Collection .............................. 400

7.4 Objekte in Aktion und in Interaktion ............................................ 4127.4.1 UML: Diagramme zur Beschreibung von Abläufen........... 4127.4.2 Nachrichten an Objekte ................................................. 4217.4.3 Iteratoren und Generatoren ........................................... 4217.4.4 Funktionsobjekte und ihr Einsatz als Eventhandler .......... 4337.4.5 Kopien von Objekten ..................................................... 4427.4.6 Sortierung von Objekten ................................................ 452

7.5 Kontrakte: Objekte als Vertragspartner ......................................... 4557.5.1 Überprüfung von Kontrakten ......................................... 4557.5.2 Übernahme von Verantwortung:

Unterklassen in der Pflicht ............................................. 4577.5.3 Prüfungen von Kontrakten bei Entwicklung

und Betrieb .................................................................... 4707.6 Exceptions: Wenn der Kontrakt nicht eingehalten werden kann .... 471

7.6.1 Exceptions in der Übersicht ............................................ 4727.6.2 Exceptions und der Kontrollfluss eines Programms.......... 4787.6.3 Exceptions im Einsatz bei Kontraktverletzungen .............. 4847.6.4 Exceptions als Teil eines Kontraktes ............................... 4887.6.5 Der Umgang mit Checked Exceptions ............................. 4937.6.6 Exceptions in der Zusammenfassung .............................. 501


Inhalt

11

Wir betrachten in diesem Kapitel anhand einer Reihe von Beispielen, wie objektorientierte Entwürfe in größere Kontexte eingebunden werden. Dabei diskutieren wir die verschiedenen Arten, mit denen Module in diesen Kontexten angepasst und erweitert werden können. Am Beispiel des Musters Model-View-Controller stellen wir vor, wie objektorientierte Verfahren Beiträge zueiner kompletten Systemarchitektur leisten können. 503

8 Module und Architektur ............................................................ 503

8.1 Module als konfigurierbare und änderbare Komponenten ............. 5038.1.1 Relevanz der Objektorientierung für

Softwarearchitektur ........................................................ 5038.1.2 Erweiterung von Modulen .............................................. 505

8.2 Die Präsentationsschicht: Model, View, Controller (MVC) .......................................................................... 5118.2.1 Das Beobachter-Muster als Basis von MVC .................... 5128.2.2 MVC in Smalltalk: Wie es ursprünglich mal war............... 5138.2.3 MVC: Klärung der Begriffe ............................................. 5148.2.4 MVC in Webapplikationen: genannt »Model 2« .............. 5188.2.5 MVC mit Fokus auf Testbarkeit:

Model-View-Presenter ................................................... 523

In diesem Kapitel stellen und klären wir die Frage, ob aspektorientierte Programmierung ein neues Paradigma ist oder eine Ergänzung zu objektorientierten Techniken. Wir nehmen die Antwort hier schon einmal ganz kurz vorweg: Aus unserer Sicht ist Aspektorientierung eine Ergänzung der Objektorientierung, die in Zukunft einige bestehende Defizite ausbügeln könnte. 527

9 Aspekte und Objektorientierung ............................................... 527

9.1 Trennung der Anliegen ................................................................. 5279.1.1 Kapselung von Daten ..................................................... 5319.1.2 Lösungsansätze zur Trennung von Anliegen .................... 532

9.2 Aspektorientiertes Programmieren ................................................ 5399.2.1 Integration von aspektorientierten Verfahren in

Frameworks ................................................................... 5399.2.2 Bestandteile der Aspekte ............................................... 5419.2.3 Dynamisches Crosscutting .............................................. 5419.2.4 Statisches Crosscutting ................................................... 548

9.3 Anwendungen der Aspektorientierung .......................................... 5509.3.1 Zusätzliche Überprüfungen während der Übersetzung..... 5519.3.2 Logging .......................................................................... 5529.3.3 Transaktionen und Profiling ........................................... 5539.3.4 Design by Contract ........................................................ 5569.3.5 Introductions ................................................................. 5599.3.6 Aspektorientierter Observer ........................................... 560

9.4 Annotations .................................................................................. 5629.4.1 Zusatzinformation zur Struktur eines Programms............. 5639.4.2 Annotations im Einsatz in Java und C# ........................... 5659.4.3 Beispiele für den Einsatz von Annotations ...................... 566


Inhalt

12

In diesem Praxiskapitel werden wir die besprochenen Prinzipien an einem konkreten Anwendungsfall demonstrieren. 573

10 Objektorientierung am Beispiel: Eine Web-Applikation mit PHP 5 und Ajax .............................. 573

10.1 OOP in PHP .................................................................................. 57410.1.1 Klassen in PHP ............................................................... 57410.1.2 Dynamische Natur von PHP ........................................... 578

10.2 Das entwickelte Framework – Trennung der Anliegen – Model View Controller ................................................ 57810.2.1 Trennung der Daten von der Darstellung ........................ 579

10.3 Ein Dienst in PHP ......................................................................... 58010.3.1 Datenmodell .................................................................. 58110.3.2 Dienste – Version 1 ........................................................ 583

10.4 Ein Klient in Ajax .......................................................................... 58610.4.1 Bereitstellung der Daten ................................................ 58710.4.2 Darstellung der Daten .................................................... 589

10.5 Ein Container für Dienste in PHP .................................................. 59810.5.1 Dispatcher ..................................................................... 60110.5.2 Fabrik ............................................................................ 60310.5.3 Dependency Injection .................................................... 60410.5.4 Sicherheit ....................................................................... 610

10.6 Ein Klient ohne JavaScript ............................................................. 61510.7 Was noch übrigbleibt .................................................................... 619

621

Anhang ............................................................................................. 621

A Verwendete Programmiersprachen .......................................................... 623A.1 C++ .............................................................................................. 623A.2 Java .............................................................................................. 626A.3 C# ................................................................................................ 629A.4 JavaScript ..................................................................................... 629A.5 CLOS ............................................................................................ 632A.6 Python .......................................................................................... 635A.7 Ruby ............................................................................................. 637

B Literaturverzeichnis ................................................................................. 641B.1 Allgemeine Bücher zur Softwareentwicklung ................................. 641B.2 Bücher über die UML und die verwendeten

Programmiersprachen ................................................................... 643

Index ............................................................................................................. 645


13

In diesem Kapitel stellen die Autoren sich und dieses Buch vor. Sie erklären, was Objektorientierung im Bereich der Software-entwicklung bedeutet. Und am Ende des Kapitels geraten sie auch schon in die erste Diskussion miteinander.

1 Einleitung

1.1 Was ist Objektorientierung?

Objektorientierung ist eine mittlerweile bewährte Methode, um dieKomplexität von Softwaresystemen in den Griff zu bekommen. Die Ent-wicklung der Objektorientierung als Konzept der Softwaretechnik istsehr eng mit der Entwicklung von objektorientierten Programmierspra-chen verbunden.

Von Alan Kay, dem Erfinder der Sprache Smalltalk, die als die erste kon-sequent objektorientierte Programmiersprache gilt, wird die folgendeGeschichte erzählt:

Bei einer Präsentation bei Apple Mitte der 80er-Jahre hielt ein Mit-arbeiter einen Vortrag über die erste Version der neu entwickeltenProgrammiersprache Oberon. Diese sollte der nächste große Schrittin der Welt der objektorientierten Sprachen sein.

Da meldete sich Alan Kay zu Wort und hakte nach:

»Diese Sprache unterstützt also keine Vererbung?«»Das ist korrekt.«»Und sie unterstützt keine Polymorphie?«»Das ist korrekt.«»Und sie unterstützt auch keine Datenkapselung?«»Das ist ebenfalls korrekt.«»Dann scheint mir das keine objektorientierte Sprache zu sein.«

Der Vortragende meinte darauf: »Nun, wer kann schon genau sagen,was nun objektorientiert ist und was nicht.«

Woraufhin Alan Kay zurückgab: »Ich kann das. Ich bin Alan Kay,und ich habe den Begriff geprägt.«


14

Einleitung1

Der geschilderte Dialog enthält genau die drei Grundelemente, die alsBasis von objektorientierten Programmiersprachen gelten:

� Unterstützung von Vererbungsmechanismen

� Unterstützung von Datenkapselung

� Unterstützung von Polymorphie

Auf alle drei Punkte werden wir eingehen. Objektorientierung geht aller-dings mittlerweile weit über diese Grunddefinition hinaus. Die genann-ten Punkte bilden lediglich den kleinsten gemeinsamen Nenner.

1.2 Hallo liebe Zielgruppe

Die Frage »Für wen schreiben wir dieses Buch?« haben wir uns beimSchreiben selbst immer wieder gestellt.

Die Antwort darauf hängt eng mit der Frage zusammen, warum wireigentlich dieses Buch geschrieben haben. Nun, neben dem ganz offen-sichtlichen Grund, dass die Veröffentlichung die beiden Autoren reichund berühmt machen wird, was ja ein ganz angenehmer Nebeneffekt ist,gibt es noch einen ganz zentralen weiteren Grund: Wir wollten das Buchschreiben, das wir uns selbst an bestimmten Punkten unseres Ausbil-dungswegs und unserer Berufslaufbahn gewünscht hätten.

Wir haben uns beide von Anfang an im Umfeld der objektorientiertenSoftwareentwicklung bewegt. Allerdings unterschied sich das, was wir inder Praxis an Anforderungen vorfanden, dann doch stark von dem, wasUniversität und Lehrbücher vorbereitet hatten.

Theorie und Praxis Aufgrund dieser Erfahrung hätten wir uns ein Buch gewünscht, das denBrückenschlag zwischen Theorie und Praxis bewerkstelligt. Nicht mal sosehr auf der Ebene von praktischen Programmen, sondern eher: Wiewerden die theoretischen Ansätze (die wir Prinzipien nennen) denn nunumgesetzt? Was hat es mit dem Thema Garbage Collection auf sich? Wasist denn wirklich mit Model-View-Controller gemeint? Warum müssenwir uns denn überhaupt mit tiefen Kopien, flachen Kopien, Identität,Gleichheit beschäftigen?

Wir glauben, dass wir es ein Stück in diese Richtung geschafft haben undIhnen eine interessante Verbindung aus Theorie und Praxis präsentieren.

Wer sollte unserBuch lesen?

Wir wollen Studenten der Informatik eine praktische, interessante undhoffentlich auch unterhaltsame Einführung und Vertiefung zum Thema


15

Was bietet dieses Buch (und was nicht)? 1.3

Objektorientierung bieten. Wir wollen Berufseinsteigern im BereichSoftwareentwicklung einen leichteren Start ermöglichen, indem wirBegriffe praktisch klären, mit denen sie regelmäßig konfrontiert werden.Wir wollen im Beruf aktiven Softwareentwicklern die Chance geben, ein-fach noch mal darüber nachzudenken, was sie eigentlich in der täglichenArbeit so machen und ob nicht vielleicht noch die eine oder andere Ver-besserung möglich ist.

Wir wenden uns also an Softwareentwickler in Ausbildung oder im akti-ven Einsatz, an Menschen, die Programme schreiben. Natürlich würdenwir uns auch freuen, wenn Projektleiter und Projektmanager unser Buchin die Hand nehmen. Geschrieben haben wir es allerdings als Software-entwickler für andere Softwareentwickler.

Was wir voraussetzen

Als Voraussetzung gehen wir davon aus, dass unsere Leser grundsätzli-che Erfahrung mit der Programmierung haben. Erfahrungen mit der Pro-grammierung in objektorientierten Sprachen sind hilfreich, obwohlnicht unbedingt notwendig. Unser Buch wendet sich damit auch explizitan Menschen, die bereits mit Programmiersprachen arbeiten, die objekt-orientierte Mechanismen anbieten, wie dies zum Beispiel bei Java derFall ist. Da aber nur durch die Verwendung von objektorientierten Spra-chen noch lange keine objektorientierte Software entsteht, wollen wirmit unserem Buch genau diesen Schritt ermöglichen.

Wir werden zu den verwendeten Programmiersprachen keine detail-lierte Einführung geben. Stattdessen findet sich im Anhang jeweils eineKurzbeschreibung der jeweiligen Programmiersprache. Diese erläutertdie grundlegenden Sprachkonstrukte mit Bezug zur objektorientiertenProgrammierung. Außerdem geben wir Verweise auf weitere Informati-onsquellen zur Programmiersprache, sofern möglich auch mit Hinweisenauf verfügbare freie Versionen von Compilern, Interpretern oder Ent-wicklungsumgebungen.

1.3 Was bietet dieses Buch (und was nicht)?

Objektorientierung ist eine Vorgehensweise, die den Fokus auf modulareSysteme legt. Dieses Modulprinzip legen wir in zweierlei Hinsicht auchdiesem Buch zugrunde.

Zum einen sehen wir das Buch als einen Baustein, der beim Verständnisdes Themas Objektorientierung eine zentrale Rolle spielt. Wir beschrei-ben, wie Sie Objektorientierung einsetzen können, um auf der Grund-


16

Einleitung1

lage von zentralen Prinzipien beherrschbare und änderbare Softwareerstellen können. Wenn wir auf diesem Weg an Entwurfsmustern vor-beikommen, werden wir diese vorstellen und ihren Nutzen für den Ent-wurf oder die aktuelle Problemstellung erläutern.

Zum anderen bauen die Kapitel des Buchs modular aufeinander auf. Aus-gehend von abstrakten Prinzipien gehen wir immer weiter in die kon-krete Anwendung der Objektorientierung. Diesen modularen Aufbauwollen wir in einer Übersicht kurz vorstellen.

1.3.1 Bausteine des Buchs

Abbildung 1.1 stellt die einzelnen Kapitel als Bausteine in der Übersichtdar.

Abbildung 1.1 Modularer Aufbau der Kapitel

Kapitel 2:Basis

In Kapitel 2, »Die Basis der Objektorientierung«, stellen wir zunächst diegrundlegenden Unterschiede der objektorientierten Vorgehensweise imVergleich zur strukturierten Programmierung vor. Wir beschreiben dortauch im Überblick die Basismechanismen der Objektorientierung:Datenkapselung, Polymorphie und Vererbung.

Kapitel 2 : Die Basis der Objektorientierung

Kapitel 3 : Die Prinzipien des objektorientierten Entwurfs

U M

L

Kapitel 4 : Die Struktur objektorientierter Software

Kapitel 5 : Vererbung und Polymorphie

Kapitel 6 : Persistenz

Kapitel 7 : Abläufe in einem objektorientierten System

Kapitel 8: Module und Architektur

E n t

w u

r f s m

u s t

e r

Kapitel 9 : Aspekte und Objektorientierung

Kapitel 10: Objektorientierungam Bespiel: Eine Web-Applikation

mit PHP 5 und Ajax


17


Kapitel 3: Prinzipien

Danach schließt sich Kapitel 3, »Die Prinzipien des objektorientiertenEntwurfs«, an. Das Kapitel stellt die grundlegenden Prinzipien vor, diefür den objektorientierten Ansatz entscheidend sind. In Abschnitt 1.1haben wir einen kleinen Dialog vorgestellt, in dem die grundlegendenEigenschaften von objektorientierten Sprachen angesprochen werden.Genau wie die dort genannten Eigenschaften geben auch die Prinzipiender Objektorientierung einen Rahmen für eine bestimmte Art der Soft-wareentwicklung vor. Die Prinzipien sind zentral für das Vorgehen beider Entwicklung von objektorientierter Software. Das Kapitel legt alsodie grundsätzliche Basis, ohne bereits detailliert auf Objekte, Klassenoder Ähnliches einzugehen.

Kapitel 4: Struktur

Anschließend erläutern wir in Kapitel 4, »Die Struktur objektorientierterSoftware«, das Konzept von Objekten, Klassen und der darauf aufbauen-den Möglichkeiten. Wir erläutern das Konzept der Klassifizierung undbetrachten die Rolle der Klassen als Module. Den verschiedenen Arten,in denen Objekte untereinander in Beziehung stehen können, ist eben-falls ein Teilkapitel gewidmet.

Kapitel 5: Vererbung und Polymorphie

In Kapitel 5, »Vererbung und Polymorphie«, gehen wir darauf ein, wiedie Vererbung der Spezifikation – im Zusammenspiel mit der Fähigkeitder Polymorphie – Programme flexibel und erweiterbar halten kann. Wirgehen dabei auf die verschiedenen Varianten der Vererbung im Detailein und stellen deren Möglichkeiten und Probleme vor. An Beispielenerläutern wir dabei auch, wie die Möglichkeiten der Polymorphie ambesten genutzt werden können.

Kapitel 6: Persistenz

Kapitel 6, »Persistenz«, beschreibt, wie Objekte in relationalen Daten-banken gespeichert werden können. In fast allen Anwendungen tauchtdie Notwendigkeit auf, dass Objekte persistent gespeichert werden müs-sen. Wir stellen die Abbildungsregeln für Vererbungsbeziehungen undandere Beziehungen zwischen Objekten und Klassen auf eine relationaleDatenbank vor. Schließlich setzen wir diese Abbildungsregeln in Bezie-hung zu den verschiedenen Stufen der Normalisierung in einer relationa-len Datenbank.

Kapitel 7: Abläufe

In Kapitel 7, »Abläufe in einem objektorientierten System«, beschreibenwir die Vorgänge innerhalb des Lebenszyklus von Objekten. Wir gehendetailliert auf die Erzeugung von Objekten ein und erläutern, wie Sie einSystem erweiterbar halten, indem Sie möglichst flexible Methoden derObjekterzeugung einsetzen. Außerdem enthält das Kapitel Beschreibun-gen von Interaktionsszenarien, die sich häufig in objektorientierten Sys-temen finden. Der Abschluss des Objektlebenszyklus, der meist über den


18

Einleitung1

Mechanismus der Garbage Collection stattfindet, wird ebenfalls in die-sem Kapitel beschrieben.

Kapitel 8:Architektur

In Kapitel 8, »Module und Architektur«, stellen wir Beispiele dafür vor,wie objektorientierte Entwürfe in reale Systeme integriert werden. Wirstellen das Konzept von in der Praxis verwendeten Ansätzen wie Frame-works und Anwendungscontainern vor. Am Beispiel der Präsentations-schicht einer Anwendung erläutern wir, wie objektorientierte Verfahrendie Interaktionen in einem System strukturieren können. Dazu stellenwir das Architekturmuster Model-View-Controller (MVC) und dessenEinsatzszenarien vor.

Kapitel 9:Aspekte

In Kapitel 9, »Aspekte und Objektorientierung«, stellen wir dar, wie sicheine Reihe von Einschränkungen der objektorientierten Vorgehensweisedurch Aspektorientierung aufheben lässt. Wir erläutern, welcheBeschränkungen der objektorientierten Vorgehensweise überhaupt zurNotwendigkeit einer aspektorientierten Sichtweise führen. Die Verwal-tung von sogenannten übergreifenden Anliegen (engl. Crosscutting Con-cerns) ist mit den Mitteln der klassischen objektorientierten Programmie-rung nur sehr aufwändig zu realisieren. Bei Crosscutting Concernshandelt es sich um Anforderungen, die mit Mitteln der Objektorientie-rung nur klassenoder komponentenübergreifend realisiert werdenkönnen.

Deshalb zeigen wir in diesem Kapitel verschiedene Möglichkeiten auf,Lösungen dafür in objektorientierte Systeme zu integrieren. Wir erläu-tern den Weg zu den aspektorientierten Lösungen und stellen diese anpraktischen Beispielen vor.

Kapitel 10:Objektorien-

tierung amBeispiel einer

Web-Applikation

Abgerundet wird unser Buch dann durch Kapitel 10, »Objektorientie-rung am Beispiel: Eine Web-Applikation mit PHP 5 und Ajax«. Dort grei-fen wir am Beispiel einer Web-Anwendung eine ganze Reihe von Kon-zepten auf, die in den vorhergehenden Kapiteln erläutert wurden. ImKontext einer einfachen, aber vollständigen Web-Anwendung auf Basisvon PHP 5 und Ajax stellen wir Schritt für Schritt vor, wie Geschäftslogikund Präsentationsschicht durch objektorientierte Vorgehensweisen klarvoneinander entkoppelt werden. Dabei gehen wir auch darauf ein, durchwelchen Aufbau ein Austausch von Teilen der Präsentationsschichterleichtert wird.

Anhang:Programmier-

sprachen

Im Anhang werden wir die im Buch verwendeten Programmiersprachenjeweils mit einer Kurzreferenz vorstellen und Hinweise auf weitere Infor-mationen geben.


19


1.3.2 Crosscutting Concerns: übergreifende Anliegen

Die beschriebenen Kapitel bauen in Form einer Modulstruktur aufeinan-der auf. Aber ähnlich wie bei der Strukturierung objektorientierter Soft-ware gibt es natürlich auch hier Themen, die übergreifend sind und sichnicht genau einem der Kapitel zuordnen lassen.

Im Folgenden gehen wir kurz darauf ein, welche Rolle diese weiterenThemengebiete spielen.

Unified Modeling Language

Die Unified Modeling Language (UML) hat sich mittlerweile als ein sinn-volles und weit verbreitetes Modellierungsmittel durchgesetzt. Wir wer-den die nach unserer Ansicht wichtigsten Darstellungselemente der UMLanhand von Beispielen vorstellen. Wir werden diese dabei immer danneinführen, wenn die betreffende Modellierung für unser aktuell behan-deltes Thema relevant wird. Wir verwenden die UML in der Regel auchzur Illustration von Strukturen und Abläufen.

Objektorientierte Analyse

Die objektorientierte Analyse betrachtet eine Domäne als System vonkooperierenden Objekten. Obwohl objektorientierte Analysemethodennicht unser zentrales Thema sind, werden wir diese immer dann heran-ziehen, wenn wir auf die Verbindung von Analyse und Design eingehen.

Entwurfsmuster

Entwurfsmuster (engl. Design Patterns) für den objektorientierten Ent-wurf wurden mit der Publikation Entwurfsmuster: Elemente wiederver-wendbarer objektorientierter Software als Begriff geprägt. Die AutorenErich Gamma, Richard Helm, Ralph Johnson und John Vlissides führendabei eine standardisierte Beschreibungsform für wiederkehrende Vor-gehensweisen beim Entwurf guter objektorientierter Software ein1. Auf-grund von Umständen, die mit der Sortierung unseres Alphabets zusam-menhängen, wird die Publikation meist mit Erich Gamma assoziiert. Dadas aber nicht korrekt ist, werden wir uns mit dem Namen [Entwurfs-muster 2004] darauf beziehen, da die aktuelle deutsche Ausgabe aus dem

1 Allerdings sind auch die Autoren des Entwurfsmuster-Buchs mittlerweile nicht mehrbei allen der vorgestellten Muster davon überzeugt, dass es sich wirklich um emp-fehlenswerte Vorgehensweisen handelt. So hat sich beispielsweise das Entwurfs-muster »Singleton« mittlerweile einen eher fragwürdigen Ruf erarbeitet.


20

Einleitung1

Jahr 2004 stammt und eine Verwechslungsgefahr mit anderen Entwurfs-musterbüchern in diesem Jahr nicht besteht.

Grundsätzlich sind solche Entwurfsmuster unabhängig davon, ob wireine objektorientierte Vorgehensweise gewählt haben, da sie nur eineSchablone für gleichartige Problemstellungen sind. Allerdings hat sich inder Praxis herausgestellt, dass bei Verwendung von objektorientiertenMethoden diese Muster einfacher zu erkennen und besser zu beschrei-ben sind.

In der Folge ist eine ganze Reihe von unterschiedlichen Entwurfsmusternentstanden, die meisten mit Bezug auf objektorientierte Methoden. Inder Kategorie Anti-Patterns werden häufige Fehler beim Systementwurfzusammengefasst.

Wir werden eine ganze Reihe von Entwurfsmustern verwenden. Aller-dings werden wir diese dann vorstellen, wenn ein Muster ein bestimm-tes Thema gut illustriert oder dafür zentral ist. In diesem Fall geben wireine kurze Vorstellung des Musters und erläutern dessen Anwendung.

Deutsche und englische Begriffe

Wir werden außerdem weitgehend deutsche Begriffe verwenden. Wennallerdings der englische Begriff der wesentlich gängigere ist, werden wirdiesen verwenden. Dies gilt auch, wenn eine deutsche Übersetzung dieBedeutung verzerren würde oder zu umständlich wird. So werden wirzum Beispiel den Begriff Multiple Dispatch verwenden, weil die in Fragekommenden Übersetzungen Multiple Verteilung oder Verteilung auf derGrundlage von mehreren Objekten nicht wesentlich erhellender oder abersehr umständlich sind.

Wir werden die englische Entsprechung bei der ersten Erwähnung meistmit aufführen. So werden wir zum Beispiel das Prinzip Offen für Erweite-rung, geschlossen für Änderung bei der ersten Erwähnung auch als OpenClosed Principle vorstellen.

1.3.3 Die Rolle von Programmiersprachen

Die meisten der von uns diskutierten Prinzipien der Objektorientierungfinden sich in den objektorientierten Programmiersprachen wieder, ent-weder als direkte Sprachkonstrukte oder als Möglichkeiten bei der Pro-grammierung.


21


Allerdings: Die Unterstützung variiert sehr stark zwischen den einzelnenobjektorientierten Sprachen. Bestimmte Prinzipien werden nur vonwenigen Sprachen unterstützt, andere in unterschiedlichem Ausmaß.

Wir haben deshalb eine überschaubare Anzahl von Programmierspra-chen ausgewählt, um diese jeweils dann als Beispiel heranzuziehen,wenn ein bestimmtes Prinzip besonders gut (oder vielleicht auch beson-ders schlecht) unterstützt wird.

Objektorientierte Softwareentwicklung lässt sich nicht beschreiben,ohne auf die Entwicklung der objektorientierten Programmierspracheneinzugehen. Durch ihre jeweils spezifischen Möglichkeiten sind Pro-grammiersprachen selbst sehr gute Beispiele dafür, wie Konzepte derObjektorientierung in der Praxis umgesetzt werden.

Alan Perlis hatte mit seiner Aussage völlig Recht, als er schrieb: Eine Pro-grammiersprache, die nicht die Art beeinflusst, in der du über das Program-mieren nachdenkst, ist es nicht wert, dass man sie kennt.2

Deshalb werden Sie in den folgenden Kapiteln auch einiges über dieBesonderheiten und speziellen Möglichkeiten von mehreren objektori-entierten Sprachen erfahren. Alleine schon durch die Betrachtung derUnterschiede zwischen einzelnen Sprachen lassen sich Konzepte gutillustrieren. Jede der Sprachen hat ihre eigenen Stärken, jede machtbestimmte Sachen einfach. Jede hat ihre eigenen Idiome und Muster.

Wenn man mehrere Programmiersprachen kennt, lernt man oft neueVorgehensweisen. Auch wenn man in der Praxis die meiste Zeit nur miteiner Programmiersprache arbeitet, lohnt es sich, auch einen Blick aufandere zu werfen. Vielleicht nur um die ausgetretenen Pfade zu verlassenund zu erkennen, dass manche Aufgaben, die man für schwierig hielt,sich in Wirklichkeit ganz einfach lösen lassen.

Hier also die Liste der Programmiersprachen, die sich in den Code-Bei-spielen wiederfinden:

� JavaJava ist natürlich dabei, weil es mittlerweile eine sehr verbreiteteSprache ist, die einen Fokus auf Objektorientierung setzt.

2 Das Originalzitat in Englisch lautet: »A language that doesn't affect the way you thinkabout programming, is not worth knowing.« und ist enthalten in einem Artikel vonAlan Perlis in den SIGPLAN Notices Vol. 17, No. 9, September 1982.


22

Einleitung1

� C++Auch C++ hat immer noch einen hohen Verbreitungsgrad und unter-stützt die Basisprinzipien der Objektorientierung zu großen Teilen.

� JavaScriptJavaScript wird hauptsächlich als Beispiel für eine objektorientierteSprache, die mit Prototypen arbeitet, angeführt.

� RubyRuby ist eine Skriptsprache, die wegen ihrer einfachen und intuitivenHandhabung immer beliebter wird. Ruby hat einen sehr starkenFokus auf Objektorientierung. Außerdem sind Klassenerweiterungen(Mixins) möglich.

� C#Die von Microsoft entwickelte Sprache aus der .NET-Familie fasst eineganze Reihe von Konzepten der Objektorientierung gut zusammen.

� PythonPython ist eine interaktive objektorientierte Skriptsprache, die nachder britischen Komikertruppe Monty Python benannt ist. Pythonbetrachtet alle im Programm vorhandenen Daten als Objekte.

Wir werden Beispiele in den verschiedenen Sprachen immer dann ein-bringen, wenn sich eine Sprache gerade besonders gut zur Illustration eig-net. Außerdem werden wir zur Erläuterung der aspektorientierten Erwei-terungen zur Objektorientierung hauptsächlich AspectJ heranziehen.

1.4 Warum überhaupt Objektorientierung?

Wir wollen hier zunächst einmal eine Aussage vorausschicken, die trivialanmuten mag: Es ist nicht einfach, gute Software zu entwickeln. Spezielldie Komplexität von mittleren und großen Softwaresystemen stellt oftein großes Problem dar.

Objektorientierte Softwareentwicklung ist nicht die einzige Methode,um diese Komplexität in den Griff zu bekommen, aber sie hat sich in ver-schiedenen Anwendungskontexten bewährt. Außerdem liefert sie mit-tlerweile ein Instrumentarium für eine ganze Reihe von Problemfeldern.

Objektorientierte Vorgehensweisen ergänzen sich außerdem gut miteinigen anderen Ansätzen in der Softwareentwicklung. Deshalb ist das


23

Warum überhaupt Objektorientierung? 1.4

letzte Kapitel auch dem Thema Aspektorientierung gewidmet, da dieserAnsatz einige der Defizite der objektorientierten Vorgehensweise ausbü-geln kann.

1.4.1 Gute Software: Was ist das eigentlich?

Je nachdem, wen wir fragen, wird die Antwort auf die Frage »Was machtgute Software für Sie aus?« unterschiedlich ausfallen.

Fragen wir doch zunächst den Anwender von Software. Das sind wir japraktisch alle. Hier werden wir häufig die folgenden Anforderungenhören:

� Software soll das machen, was ich von ihr erwarte: Software musskorrekt sein.

� Software soll es mir möglichst einfach machen, meine Aufgabe zuerledigen: Software muss benutzerfreundlich sein.

� Ich möchte meine Arbeit möglichst schnell und effizient erledigen,ich möchte keine Wartezeiten haben: Software muss effizient undperformant sein.

Fragen wir nun denjenigen, der für Software und Hardware bezahlt,kommen weitere Anforderungen hinzu:

� Ich möchte keine neue Hardware kaufen müssen, wenn ich die Soft-ware einsetze: Software muss effizient mit Ressourcen umgehen.

� Ich möchte, dass die Software möglichst günstig erstellt werden kann.

� Mein Schulungsaufwand sollte gering sein.

Fragen wir den Projektmanager, der die Entwicklung der Software voran-treiben soll, dann kommt noch mehr zutage:

� Meine Auftraggeber kommen oft mit neuen Ideen. Es darf nicht auf-wändig sein, diese neuen Ideen auch später noch umzusetzen: Soft-ware muss sich anpassen lassen.

� Ich habe feste Zieltermine, das Management sitzt mir im Nacken. Des-halb muss ich diese Software in möglichst kurzer Zeit fertigstellen.

� Das Programm soll über Jahre hinweg verwendet werden. Ich mussÄnderungen auch dann noch mit überschaubarem Aufwand umset-zen können.


24

Einleitung1

Trotz der unterschiedlichen Sichtweisen kristallisieren sich hier einigezentrale Kriterien für gute Software heraus3:

� KorrektheitSoftware soll genau das tun, was von ihr erwartet wird.

� BenutzerfreundlichkeitSoftware soll einfach und intuitiv zu benutzen sein.

� EffizienzSoftware soll mit wenigen Ressourcen auskommen und gute Antwort-zeiten für Anwender haben.

� WartbarkeitSoftware soll mit wenig Aufwand erweiterbar und änderbar sein.

Ein Hauptfeind dieser Kriterien ist die Komplexität, die sich in der Regelbei Softwaresystemen mit zunehmender Größe aufbaut.

1.4.2 Die Rolle von Prinzipien

Wenn wir Sie motivieren wollen, dass Sie objektorientierte Methodeneinsetzen sollten, müssen wir drei verschiedene Arten von Fragen stel-len:

1. Welche Probleme wollen Sie eigentlich angehen? Häufig wird die Auf-gabenstellung sein, die bereits genannten Kriterien wie Korrektheit,Benutzerfreundlichkeit, Effizienz und Wartbarkeit einzuhalten.

2. Welche abstrakten Prinzipien helfen Ihnen dabei? Beispiele sind hierKapselung von Information oder klare Zuordnung von Veranwortlich-keiten zu Modulen.

3. Wie können Sie diese Prinzipien in einem Softwaresystem sinnvollumsetzen?

Da Objektorientierung eben nur eine Methode ist, um diese Ziele umzu-setzen, ist es beim Entwurf von Systemen immer wichtig, dass Sie sichbewusst sind, warum Sie einen bestimmten Entwurf gewählt haben.

Am Ende kommt es darauf an, den ursprünglichen Zielen möglichst nahezu kommen. Sie werden dabei oft Kompromisse finden müssen. Die mit

3 Neben den aufgelisteten Kriterien gibt es noch weitere allgemeine Anforderungenan Software. Es ist von der jeweiligen Anwendung abhängig, wie zentral die jewei-lige Anforderung ist. So ist für Software zur Steuerung eines Atomkraftwerks Kor-rektheit und Fehlertoleranz wichtiger als der effiziente Umgang mit Ressourcen.


25

Warum überhaupt Objektorientierung? 1.4

der objektorientierten Vorgehensweise verbundenen Prinzipien sinddabei Richtlinien, diese müssen aber oft gegeneinander abgewogen wer-den.

Deshalb beginnen wir in Kapitel 3, »Die Prinzipien des objektorientier-ten Entwurfs«, auch mit der Vorstellung dieser grundlegenden Prinzi-pien, die der objektorientierten Softwareentwicklung zugrunde liegen.Zum überwiegenden Teil können diese völlig unabhängig von Begriffenwie Klasse oder Objekt vorgestellt werden. Erst nach der Einführung derPrinzipien werden wir also erklären, wie diese mittels Klassen undObjekten umgesetzt werden können.

1.4.3 Viele mögliche Lösungen für ein Problem

Auch wenn Sie sich einmal entschieden haben, nach dem objektorien-tierten Paradigma vorzugehen, werden für eine Problemstellung häufigverschiedene Lösungen möglich sein.

Obwohl sich die beiden Autoren grundsätzlich darüber einig sind, dassobjektorientierte Techniken zu sinnvollen Problemlösungen führen,ergeben sich hinsichtlich der in einem konkreten Fall zu wählendenLösung doch häufig Differenzen.

Diskussionen können hilfreich sein.

In so einem Fall werden wir die resultierende Diskussion einfach ganzoffen vor unserer Leserschaft austragen und diese dabei mit Beispielenaus unseren praktischen Erfahrungen mit Objekttechnologie unterfüt-tern. Das wird ein ganz schön lebhaftes Buch werden, das können wir andieser Stelle schon versprechen.

Diskussion:Was gibt’s denn hier zu diskutieren?

Gregor: Findest du das denn eine gute Idee, einfach vor unseren Leserinnenund Lesern zu diskutieren? Bestimmt erwarten sie doch, dass wir uns aufunserem Fachgebiet einig sind und auch klare Lösungen vorstellen. Ich weißnatürlich, dass wir uns wirklich nicht immer einig sind, aber wir könntendoch zumindest so tun.

Bernhard: Nun, wenn wir ständig diskutieren würden, wäre das sicherlichetwas irritierend. Und wir sind uns ja auch größtenteils einig, in vielen Fällengibt es einfach auch generell anerkannte Vorgehensweisen. Aber spannendwird das Ganze erst an den Punkten, an denen das Vorgehen eben nicht mehrvöllig klar ist und wir uns für eine von mehreren möglichen Vorgehensweisenentscheiden müssen.

Gregor: Stimmt schon, hin und wieder so eine kleine Diskussion zwischen-durch war ja auch beim Schreiben des Buchs durchaus nützlich. Dann lassuns jetzt aber loslegen. Die nächste Diskussion kommt bestimmt bald.


26

Einleitung1

Icons Um Ihnen die Orientierung im Buch zu erleichtern, haben wir zwei Iconsverwendet:

Hier finden Sie hilfreiche Definitionen, die die wesentlichen Aspekte desThemas zusammenfassen.

Konkrete Beispiele erleichtern Ihnen das Verstehen.

Weiterführende Informationen finden Sie auf der Webseite zum Buchunter www.objektorientierte-programmierung.de.

01.fm Seite 26 Montag, 9. März 2009 10:09 10

39

Prinzipien helfen uns, das Richtige zu tun. Dies gilt in der Softwareentwicklung genauso wie in unserem täglichen Leben. Wir müssen uns allerdings auch vor Prinzipienreiterei hüten und hin und wieder ein Prinzip beiseite legen können. In diesem Kapitel beschreiben wir die grundlegenden Prinzipien, die einem guten objektorientierten Softwareentwurf zugrunde liegen und warum ihre Einhaltung meistens eine gute Idee ist.

3 Die Prinzipien des objektorientierten Entwurfs

Software ist eine komplizierte Angelegenheit. Es ist nicht einfach,menschliche Sprache zu erkennen, einen Cache effektiv zu organisierenoder eine Flugbahn in Echtzeit zu berechnen. Mit dieser Art der Komple-xität, Komplexität der verwendeten Algorithmen, beschäftigen wir unsin diesem Buch jedoch nicht.

Einfache Aufgaben – komplexe Programme

Einen Text auszugeben, auf das Drücken einer Taste zu reagieren, Kun-dendaten aus einer Datenbank herauszulesen und sie zu bearbeiten – dassind einfache Programmieraufgaben. Und aus diesen einfachen Funktio-nen entstehen komplexe Programme. Unser Teufel steckt nicht imDetail, sondern in der großen Anzahl der einfachen Funktionen und derNotwendigkeit, diese zu organisieren.

Vorbereitung auf Änderungen

Außerdem ändern sich die Anforderungen an Software in der Praxis sehrhäufig. Auch das macht Softwareentwicklung zu einer kompliziertenAngelegenheit, da wir immer auf diese Änderungen vorbereitet seinmüssen.

Es ist unsere Aufgabe – Aufgabe der Softwarearchitekten, Softwaredesig-ner und Softwareentwickler –, die Programme so zu organisieren, dasssie nicht nur für die Anwender, sondern auch für uns, als Beteiligte beider Entwicklung von Software, beherrschbar werden und auch bleiben.

In diesem Kapitel stellen wir Prinzipien vor, die bei der Beherrschungder Komplexität helfen. In den darauf folgenden Kapiteln werden wirzeigen, ob und wie diese Prinzipien in der objektorientierten Program-


40

Die Prinzipien des objektorientierten Entwurfs3

mierung eingehalten werden können. Allerdings: Prinzipien kann man janie genug haben. Die Auflistung ist deshalb nicht vollständig, sie enthältaber die wichtigsten Prinzipien.

3.1 Prinzip 1: Prinzip einer einzigen Verantwortung

Das grundsätzliche Prinzip der Komplexitätsbeherrschung und Organisa-tion lautet: Teile und herrsche. Denn Software besteht aus Teilen.

In diesem Kapitel wollen wir uns nicht mit spezifisch objektorientiertenMethoden beschäftigen. Deswegen werden wir hier meistens nicht spe-zifisch über Objekte, Klassen und Typen schreiben, sondern verwendenstattdessen den Begriff Modul.

Module undUntermodule

Module selbst können aus weiteren Modulen zusammengesetzt sein, denUntermodulen. Ist ein Modul zu kompliziert, sollte es unterteilt werden.Ein mögliches Indiz dafür ist, dass der Entwickler das Modul nicht mehrgut verstehen und anpassen kann.

Besteht ein Modul aus zu vielen Untermodulen, sind also die Abhängig-keiten zwischen den Untermodulen zu komplex und nicht mehr über-schaubar, sollten Sie über die Hierarchie der Teilung nachdenken. Siekönnen dann zusammengehörige Untermodule in einem Modul zusam-menfassen oder ein neues Modul erstellen, das die Abhängigkeiten zwi-schen den zusammenhängenden Untermodulen koordiniert und nachaußen kapselt.

Module

Unter einem Modul versteht man einen überschaubaren und eigenständigenTeil einer Anwendung – eine Quelltextdatei, eine Gruppe von Quelltextdateienoder einen Abschnitt in einer Quelltextdatei. Etwas, was ein Programmierer alseine Einheit betrachtet, die als ein Ganzes bearbeitet und verwendet wird.Solch ein Modul hat nun innerhalb einer Anwendung eine ganz bestimmteAufgabe, für die es die Verantwortung trägt.

Verantwortung (Responsibility) eines Moduls

Ein Modul hat innerhalb eines Softwaresystems eine oder mehrere Aufgaben.Damit hat das Modul die Verantwortung, diese Aufgaben zu erfüllen. Wir spre-chen deshalb von einer Verantwortung oder auch mehreren Verantwortungen,die das Modul übernimmt.


41

Prinzip 1: Prinzip einer einzigen Verantwortung 3.1

Bevor wir uns die Beziehungen unter den Modulen genauer anschauen,betrachten wir zuerst die Module selbst und formulieren das Prinzip, dasuns bei der Frage unterstützt, was wir denn in ein Modul aufnehmen sollen.

Jedes Modul dient also einem Zweck: Es erfüllt bestimmte Anforderun-gen, die an die Software gestellt werden.

Code mit unklaren Aufgaben

Zumindest sollte es so sein. Viel zu oft findet man in alten, gewachsenenAnwendungen Teile von totem, nicht mehr genutztem Code, die nur des-wegen noch existieren, weil einfach niemand bemerkt hat, dass sie garkeine sinnvolle Aufgabe mehr erfüllen. Noch problematischer ist es,wenn nicht erkennbar ist, welchen Zweck ein Anwendungsteil erfüllt. Eswird damit riskant und aufwändig, den entsprechenden Teil der Anwen-dung zu entfernen.

Vielleicht kennen Sie eine verdächtig aussehende Verpackung im Kühl-schrank der Kaffeeküche? Eigentlich kann der Inhalt nicht mehr genieß-bar sein. Aber warum sollten Sie es wegwerfen? Sie sind doch nicht derKühlschrankbeauftragte, und außerdem haben Sie gehört, Ihr Boss solleden schwedischen Surströmming1 mögen – warum sollten Sie das Risikoeingehen, den Boss zu verärgern?

Sie sollten von Anfang an darauf abzielen, eine solche Situation gar nichterst entstehen zu lassen, weder im Kühlschrank noch in der Software. Essollte immer leicht erkennbar sein, welchem Zweck ein Softwaremoduldient und wem die Packung verdorbener Fisch im Bürokühlschrankgehört.

Prinzip einer einzigen Verantwortung (Single Responsibility Principle)

Jedes Modul soll genau eine Verantwortung übernehmen, und jede Verant-wortung soll genau einem Modul zugeordnet werden. Die Verantwortungbezieht sich auf die Verpflichtung des Moduls, bestimmte Anforderungenumzusetzen. Als Konsequenz gibt es dann auch nur einen einzigen Grund,warum ein Modul angepasst werden muss: Die Anforderungen, für die es ver-antwortlich ist, haben sich geändert. Damit lässt sich das Prinzip auch alterna-tiv so formulieren: Ein Modul sollte nur einen einzigen, klar definierten Grundhaben, aus dem es geändert werden muss.

1 Für diejenigen, die sich im Bereich skandinavischer Spezialitäten nicht auskennen:Surströmming ist eine besondere Konservierungsmethode für Heringe. Diese wer-den dabei in Holzfässern eingesalzen und vergoren. Nach der Abfüllung in Konser-vendosen geht die Gärung weiter, so dass sich die Dosen im Lauf der Zeit regelrechtaufblähen. Geschmackssache.


42


Abbildung 3.1 Ein Kühlschrank mit unklaren Verantwortlichkeiten

Vorteile desPrinzips

Das Prinzip einer einzigen Verantwortung hört sich vernünftig an. Aberwarum ist es von Vorteil, diesem Prinzip zu folgen?

Um das zu zeigen, sollten Sie sich vor Augen halten, was passiert, wennSie das Prinzip nicht einhalten. Die Konsequenzen gehen vor allem zuLasten der Wartbarkeit der erstellten Software.

Anforderungenändern sich.

Aus Erfahrung wissen Sie, dass sich die Anforderungen an jede Softwareändern. Sie ändern sich in der Zeit, und sie unterscheiden sich vonAnwender zu Anwender. Die Module unserer Software dienen der Erfül-lung der Anforderungen. Ändern sich die Anforderungen, muss auch dieSoftware geändert werden. Zu bestimmen, welche Teile der Softwarevon einer neuen Anforderung oder einer Anforderungsänderung betrof-fen sind, ist die erste Aufgabe, mit der Sie konfrontiert werden.

Folgen Sie dem Prinzip einer einzigen Verantwortung, ist die Identifikationder Module, die angepasst werden müssen, recht einfach. Jedes Modulist genau einer Aufgabe zugeordnet. Aus der Liste der geänderten undneuen Aufgaben lässt sich leicht die Liste der zu ändernden oder neu zuerstellenden Module ableiten.


43

Prinzip 1: Prinzip einer einzigen Verantwortung 3.1

Erhöhung der Wartbarkeit

Tragen jedoch mehrere Module dieselbe Verantwortung, müssen bei derÄnderung der Aufgabe all diese Module angepasst werden. Das Prinzipeiner einzigen Verantwortung dient demnach der Reduktion der Notwen-digkeit, Module anpassen zu müssen. Damit wird die Wartbarkeit derSoftware erhöht.

Erhöhung der Chance auf Mehr-fachverwendung

Ist ein Modul für mehrere Aufgaben zuständig, wird die Wahrscheinlich-keit, dass das Modul angepasst werden muss, erhöht. Bei einem Modul,das mehr Verantwortung als nötig trägt, ist die Wahrscheinlichkeit, dasses von mehreren anderen Modulen abhängig ist, größer. Das erschwertden Einsatz dieses Moduls in anderen Kontexten unnötig. Wenn Sie nurTeile der Funktionalität benötigen, kann es passieren, dass die Abhängig-keiten in den gar nicht benötigten Bereichen Sie an einer Nutzung hin-dern. Durch die Einhaltung des Prinzips einer Verantwortung erhöhen Siealso die Mehrfachverwendbarkeit der Module (auch Wiederverwendbar-keit genannt).

Diskussion:

Mehr Verantwor-tung, mehr Ver-wendungen?

Gregor: Dass die Wiederverwendbarkeit eines Moduls steigt, wenn ich ihmnur eine Verantwortung zuordne, ist nicht immer richtig. Wenn ich einModul habe, das viel kann, steigt doch auch die Wahrscheinlichkeit, dass eineandere Anwendung aus diesen vielen Möglichkeiten eine sinnvoll nutzenkann. Wenn ich also ein Modul schreibe, das meine Kundendaten verwaltet,diese dazu noch in einer Oracle-Datenbank speichert und gleichzeitig nocheine Weboberfläche zur Verfügung stellt, über die Kunden ihre Daten selbstadministrieren können, habe ich doch einen hohen Wiederverwendungseffekt.

Bernhard: Wenn sich eine zweite Anwendung findet, die genau die gleichenAnforderungen hat, ist die Wiederverwendung natürlich so recht einfach.Aber was passiert, wenn jemand deine Oracle-Datenbank nicht benötigt undstattdessen MySQL verwendet? Oder seine Kunden gar nicht über eine Web-oberfläche administrieren möchte, sondern mit einer lokal installiertenAnwendung? In diesen Fällen ist die Wahrscheinlichkeit groß, dass dieAbhängigkeiten zu Datenbank und Weboberfläche, die wir eingebaut haben,das Modul unbrauchbar machen. Wenn wir dagegen die Verantwortung fürKundenverwaltung, Speicherung und Darstellung in separate Module verla-gern, steigt zumindest die Wahrscheinlichkeit, dass eines der Module erneutverwendet werden kann.

Gregor: Du hast Recht. Eine eierlegende Wollmilchsau wäre vielleicht ganznützlich, aber ich möchte mir nicht, nur um paar Frühstückseier zu bekom-men, Sorgen wegen BSE und der Schweinepest machen müssen.


44


Abbildung 3.2 illustriert eine Situation, in der eine untrennbare Kombi-nation eines Moduls aus Datenbank, Kunden- und Webfunktionalitätnicht brauchbar wäre. Wenn die Module einzeln einsetzbar sind und soklar definierte Verantwortungen entstehen, könnte z.B. das Modul fürdie Kundendatenverwaltung in einer neuen Anwendung einsetzbar sein.

Abbildung 3.2 Mehrfachverwendung einzelner Module von Software

Regeln zurRealisierungdes Prinzips

Wir stellen nun zwei Regeln vor, nach denen Sie sich richten können, umdem Prinzip einer einzigen Verantwortung nachzukommen.

In Abbildung 3.3 sind zwei Gruppen von Modulen dargestellt. Der Gradder Kopplung ist in den beiden Darstellungen sehr unterschiedlich.

KundendatenDatenbank

Webansicht Kundendaten

Datenbank

Webansicht

Bildschirm

Eigene Speicherung

?

Passt nicht Ein Teil lässt sich

einsetzen.

Neue Anwendung

� Regel 1: Kohäsion maximierenEin Modul soll zusammenhängend (kohäsiv) sein. Alle Teile eines Modulssollten mit anderen Teilen des Moduls zusammenhängen und voneinan-der abhängig sein. Haben Teile eines Moduls keinen Bezug zu anderenTeilen, können Sie davon ausgehen, dass Sie diese Teile als eigenständigeModule implementieren können. Eine Zerlegung in Teilmodule bietetsich damit an.

� Regel 2: Kopplung minimierenWenn für die Umsetzung einer Aufgabe viele Module zusammenarbeitenmüssen, bestehen Abhängigkeiten zwischen diesen Modulen. Man sagtauch, dass diese Module gekoppelt sind. Sie sollten die Kopplung zwi-schen Modulen möglichst gering halten. Dies können Sie oft erreichen,indem Sie die Verantwortung für die Koordination der Abhängigkeiteneinem neuen Modul zuweisen.


45

Prinzip 2: Trennung der Anliegen 3.2

Abbildung 3.3 Module mit unterschiedlichem Grad der Kopplung

In objektorientierten Systemen können Sie oft die Komplexität derAnwendung durch die Einführung von zusätzlichen Modulen reduzieren.

Vorsicht: Ver-schleierung von Abhängigkeiten

Hierbei sollten Sie aber darauf achten, dass Sie bestehende Abhängigkeitendurch die Einführung eines vermittelnden Moduls nicht verschleiern. Einenaive Umsetzung der geschilderten Regel könnte im Extremfall jeglicheKommunikation zwischen Modulen über ein zentrales Kommunikations-modul leiten. Damit hätten Sie die oben dargestellte sternförmige Kom-munikationsstruktur erreicht, jedes Modul korrespondiert nur mit genaueinem weiteren Modul. Gewonnen haben wir dadurch allerdings nichts,im Gegenteil: Sie haben die weiterhin bestehenden Abhängigkeiten mitdem einfachen Durchleiten durch ein zentrales Modul verschleiert.

Doch nach welchen Regeln sollten Sie vorgehen, um einen solchen Feh-ler nicht zu begehen? Hier können Ihnen die anderen Prinzipien eineHilfe sein.

3.2 Prinzip 2: Trennung der Anliegen

Eine Aufgabe, die ein Programm umsetzen muss, betrifft häufig mehrereAnliegen, die getrennt betrachtet und als getrennte Anforderungen for-muliert werden können.

Mit dem Begriff Anliegen bezeichnen wir dabei eine formulierbare Auf-gabe eines Programms, die zusammenhängend und abgeschlossen ist.

Im vorigen Abschnitt haben wir etwas formuliert, das sehr ähnlichklingt: Ein Modul soll genau eine Verantwortung haben.

hoher Grad an Kopplung reduziert durch ein neues Modul

Trennung der Anliegen (Separation of Concerns)

Ein in einer Anwendung identifizierbares Anliegen soll durch ein Modul reprä-sentiert werden. Ein Anliegen soll nicht über mehrere Module verstreut sein.


46


Trennen derSprache und derDarstellung von

der Anwendungs-logik

Häufig betrachtet man die Funktionalität der Anwendung, die Darstel-lung von Texten oder die grafische Darstellung der Anwendung alsunterschiedliche Anliegen, die in getrennten Modulen umgesetzt wer-den. Die Anwendungslogik ist dann in anderen Modulen als die Text-und Grafikressourcen integriert. Wenn Sie z.B. eine Internetpräsenzerstellen, ist es einfacher, die Texte und die Grafiken direkt in die Seiteneinzubauen, als sie aus einer separaten lokalisierten Quelle zu beziehen.Doch sobald Sie die Internetpräsenz parallel in mehreren Sprachen zurVerfügung stellen möchten, wird klar, dass die Trennung der Anliegen»Seitenstruktur« und »Seitensprache« eine gute Idee ist.

In Abbildung 3.4 ist eine kleine Internetpräsenz aufgeführt, die in den –im Internet sehr gebräuchlichen – Sprachen Latein und Griechischgepflegt wird.

Abbildung 3.4 Trennung der Anliegen bei der Darstellung von HTML-Seiten

In der Abbildung sind auch die Anliegen der Seitenstruktur und der Sei-tendarstellung getrennt, so dass sich unterschiedliche Darstellungsartenfür den gleichen Inhalt umsetzen lassen.

Anliegen beiOnline-Banking

Nehmen wir ein anderes Beispiel: eine Überweisung beim Online-Ban-king. Neben der fachlichen Aufgabe, einen Geldbetrag von einem Konto


47

Prinzip 3: Wiederholungen vermeiden 3.3

auf ein anderes zu übertragen, muss das Programm noch eine Reihe vonweiteren Bedingungen sicherstellen:

1. Nur berechtigte Personen können die Überweisung veranlassen.

2. Die Überweisung ist eine Transaktion. Sie gelingt entweder als Ganzesoder scheitert als Ganzes. Im Falle einer Störung wird also nicht voneinem Konto Geld abgebucht, ohne auf ein anderes gutgeschrieben zuwerden.

3. Die Kontobewegung erscheint auf den entsprechenden Kontoaus-zügen.

Die Anliegen wie die Authentifizierung und Autorisierung der Benutzer,die Transaktionssicherheit oder die Buchführung betreffen nicht nur dieFunktion »Überweisung«, sondern sehr viele andere Funktionen derOnline-Banking-Anwendung.

Anliegen in unterschiedlichen Modulen

Die Anforderungen, die diese Anliegen betreffen, lassen sich oft einfa-cher formulieren, wenn sie zusammengefasst werden und von deneigentlichen fachlichen Funktionen getrennt beschrieben werden.

Implementieren wir die Funktionalität, welche die unterschiedlichenAnliegen betrifft, in unterschiedlichen Modulen, dann werden dieModule einfacher und voneinander unabhängiger. Sie lassen sichgetrennt und einfacher testen, modifizieren und wiederverwenden.

Diskussion:

Objektorientie-rung und Tren-nung der Anliegen

Bernhard: Ist denn Objektorientierung überhaupt der richtige und der ein-zige Weg, der uns ermöglicht, die unterschiedlichen Anliegen getrennt zu ent-wickeln?

Gregor: Die Objektorientierung kann hier nur als erster Schritt betrachtetwerden, wir werden später im Buch sehen, dass die Trennung bestimmterwichtiger Arten von Anliegen nicht zu den Stärken objektorientierter Systemegehört. Dieses Problem wird durch die aspektorientierte Vorgehensweise adres-siert, dem wir das Kapitel 9, »Aspekte und Objektorientierung«, widmen.

3.3 Prinzip 3: Wiederholungen vermeiden

Wenn sich ein Stück Quelltext wiederholt, ist es oft ein Indiz dafür, dassFunktionalität vorliegt, die zu einem Modul zusammengefasst werdensollte. Die Wiederholung ist häufig ein Anzeichen von Redundanz, dasheißt, dass ein Konzept an mehreren Stellen umgesetzt worden ist.Obwohl diese sich wiederholenden Stellen nicht explizit voneinander


48


abhängig sind, besteht deren implizite Abhängigkeit in der Notwendig-keit, gleich oder zumindest ähnlich zu sein.

Wir haben in den beiden bereits vorgestellten Prinzipien von explizitenAbhängigkeiten zwischen Modulen gesprochen, bei denen ein Modulein anderes nutzt.

ImpliziteAbhängigkeiten

Implizite Abhängigkeiten sind schwieriger erkennbar und handhabbarals explizite Abhängigkeiten, sie erschweren die Wartbarkeit der Soft-ware. Durch die Vermeidung von Wiederholungen und Redundanz inQuelltexten reduzieren wir den Umfang der Quelltexte, deren Komplexi-tät und eine Art der impliziten Abhängigkeiten.

Prinzipin der Praxis

Es handelt sich hier allerdings um ein Prinzip, dem wir in der Praxis nichtimmer folgen können. Oft entstehen in einem Softwaresystem an ver-schiedenen Stellen ähnliche Funktionalitäten, deren Ähnlichkeit abernicht von vornherein klar ist. Deshalb sind Redundanzen im Code als einZwischenzustand etwas Normales. Allerdings gibt uns das Prinzip Wie-derholungen vermeiden vor, dass wir diese Redundanzen aufspüren undbeseitigen, indem wir Module, die gleiche oder ähnliche Aufgaben erle-digen, zusammenführen.

Regeln zurUmsetzung des

Prinzips

Die einfachste Ausprägung dieses Prinzips ist die Regel, dass man stattausgeschriebener immer benannte Konstanten in den Quelltexten ver-wenden sollte. Wenn Sie in einem Programm die Zahl 5 mehrfach fin-den, woher sollen Sie wissen, dass die Zahl manchmal die Anzahl derArbeitstage in einer Woche und ein anderes Mal die Anzahl der Fingereiner Hand bedeutet? Und was passiert, wenn Sie das Programm in einerBranche einsetzen möchten, in der es Vier- oder Sechstagewochen gibt?Da sollten die Anwender lieber auf ihre Finger gut aufpassen. Die Ver-wendung von benannten Konstanten wie ARBEITSTAGE_PRO_WOCHE oderANZAHL_FINGER_PRO_HAND schafft hier Klarheit.

Ein anderes Beispiel ist etwas subtiler. Stellen Sie sich vor, in IhrerAnwendung werden Kontaktdaten verwaltet. Für jede Person werdender Vor- und der Nachname getrennt eingegeben, doch meistens wirdder volle Name in der Form firstName + ' ' + lastName dargestellt. Die-sen Ausdruck finden Sie also sehr häufig im Quelltext. Ist diese Wieder-holung problematisch? Immerhin ist der Aufruf nicht viel länger als der

Wiederholungen vermeiden (Don’t repeat yourself)

Eine identifizierbare Funktionalität eines Softwaresystems sollte innerhalb die-ses Systems nur einmal umgesetzt sein.


49

Prinzip 3: Wiederholungen vermeiden 3.3

Aufruf einer Funktion fullName(). Hier kann man keine generell gültigeAntwort geben. Gibt es eine Anforderung, dass der volle Name in derForm firstName + ' ' + lastName dargestellt werden soll? Wenn ja, solltediese Anforderung explizit an einer Stelle, in der Funktion fullName()umgesetzt werden2.

Austausch von Daten

Noch interessanter wird es allerdings, wenn Sie beschließen, bestimmteDaten mit einer anderen Anwendung auszutauschen. Sie definieren eineDatenstruktur, die eine Anwendung lesen und die andere Anwendungbeschreiben kann. Diese Datenstruktur muss in beiden Anwendungengleich sein, wenn sich die Struktur in einer der Anwendungen ändert,muss sie auch in der anderen geändert werden.

Wenn Sie diese Datenstruktur in beiden Anwendungen separat definie-ren, bekommen Sie eine implizite Abhängigkeit. Wenn Sie die Strukturin nur einer Anwendung ändern, werden weiterhin beide Anwendungenlauffähig bleiben. Jede für sich alleine bleibt funktionsfähig. Doch ihreZusammenarbeit wird gestört. Sie werden inkompatibel, ohne dass Sie esbei der separaten Betrachtung der Anwendungen feststellen können.

Wenn möglich, sollten Sie also die Datenstruktur in einem neuen, mehr-fach verwendbaren Modul definieren. Auf diese Weise werden die bei-den Anwendungen explizit von dem neuen Modul abhängig. Wenn Siejetzt die Datenstruktur wegen der nötigen Änderungen einer Anwen-dung derart ändern, dass die andere Anwendung mit ihr nicht mehrumgehen kann, wird die zweite Anwendung alleine betrachtet nichtmehr funktionieren. Sie werden den Fehler also viel früher feststellenund beheben können.

Kopieren von Quelltext

Die meisten und die unangenehmsten Wiederholungen entstehen aller-dings durch das Kopieren von Quelltext. Dies kann man akzeptieren,wenn die Originalquelltexte nicht änderbar sind, weil sie zum Beispielaus einer fremden Bibliothek stammen, und die benötigten Teile nichtseparat verwendbar sind.

Häufig entstehen solche Wiederholungen aber in »quick and dirty«geschriebenen Programmen, in Prototypen und in kleinen Skripten.Wenn die Programme eine bestimmte Größe übersteigen, sollten Sie dar-

2 Es schadet aber nicht, solch eine Funktion auch ohne eine explizite Anforderungbereitzustellen und sie einzusetzen. Die Anforderungen ändern sich ja, und derQuelltext wird durch eine explizite Kapselung der Formatierung der Namen injedem Fall übersichtlicher.


50


auf achten, dass sie nicht zu »dirty« bleiben, sonst wird ihre Weiterent-wicklung auch nicht mehr so »quick« sein.

Diskussion:

Redundanz undPerformanz

Bernhard: Manchmal kann es aber doch besser sein, bestimmte Quelltextteilezu wiederholen, statt in eine separate Funktion auszulagern. So kann beihochperformanten Systemen schon das einfache Aufrufen einer Funktion zuviel Zeit beanspruchen.

Gregor: Das kann schon sein. Aber wir reden hier ausschließlich über Wieder-holungen in den von Menschen bearbeiteten Quelltexten. Der Compiler oderein nachgelagerter Quelltextgenerator kann bestimmte Funktionen als Inlinesumsetzen und auch Wiederholungen erstellen. Automatisch generierte Wie-derholungen sind, wenn es nicht übertrieben wird, kein Problem. Schließlichlautet die englische Version des Prinzips: Don’t repeat yourself. Und ich kannnur hinzufügen: Überlasse die Wiederholungen dem Compiler.

3.4 Prinzip 4: Offen für Erweiterung, geschlossen für Änderung

Ein Softwaremodul sollte sich anpassen lassen, um in veränderten Situa-tionen verwendbar zu sein. Eine offensichtliche Möglichkeit bestehtdarin, den Quelltext des Moduls zu ändern. Das ist eine vernünftige Vor-gehensweise, wenn die ursprüngliche Funktionalität des Moduls nurgenau an einer Stelle gebraucht wird und absehbar ist, dass das auch sobleiben wird.

Module inverschiedenenUmgebungen

Ganz anders sieht es aber aus, wenn das Modul in verschiedenen Umge-bungen und Anwendungen verwendet werden soll. Sicher, auch hierkönnen Sie den Quelltext des Moduls ändern, oder, besser gesagt, Siekönnen den Quelltext des Moduls kopieren, die Kopie anpassen und eineneue Variante des Moduls erstellen. Doch möchten wir jeden warnen,diesen Weg zu gehen, denn er führt direkt in die Hölle.3

Wir werden nämlich auf das folgende Problem stoßen: Die neue Variantedes Moduls wird sehr viele Gemeinsamkeiten mit dem ursprünglichenModul haben. Ergibt sich später die Notwendigkeit, die gemeinsame

3 Nein, wir meinen nicht die Hölle der ewigen Verdammnis, die nach der christlichenReligion die Sünder nach dem Tod erwartet. Zu der können wir uns (noch) nichtkompetent genug äußern. Wir meinen die Hölle der Programmierer, in der wirunsere traurigen Überstunden hier auf der Erde fristen.


51

Prinzip 4: Offen für Erweiterung, geschlossen für Änderung 3.4

Funktionalität zu ändern, müssen Sie die Änderung in allen Variantendes Moduls vornehmen.

Änderungen vermeiden

Wie können Sie die Notwendigkeit vermeiden, das Modul ändern zumüssen, wenn es in anderen Kontexten verwendet werden soll?

Betrachten wir kurz ein Beispiel aus dem realen Leben. Um gute digitaleFotos zu machen, reicht normalerweise eine einfache Kompaktkameraaus. Sie ist einfach zu handhaben, handlich und für ihren Zweck, spontanein paar Schnappschüsse zu schießen, ausreichend. Doch sie ist nichterweiterbar. In bestimmten Situationen, in denen ihr Bildsensor ausrei-chen würde, schaffen Sie es nicht, ein gutes Bild zu machen, weil dasObjektiv oder das eingebaute Blitzgerät der Lage nicht gewachsen sind.Sie können Objektiv und Blitzgerät aber auch nicht auswechseln.

Eine Spiegelreflexkamera dagegen ist für Anpassungen gebaut. Reichtdas gerade angeschlossene Objektiv nicht aus? Dann können Sie einWeitwinkel- oder ein Teleobjektiv anschließen. Ist das eingebaute Blitz-gerät zu schwach? Ein anderes lässt sich einfach aufsetzen.

Doch diese Erweiterungsmöglichkeiten haben ihren Preis – statt dasObjektiv und den Body einfach als eine Einheit herzustellen, müssen siez.B. mit einem Bajonettanschluss ausgestattet werden. Abbildung 3.5stellt die beiden Varianten gegenüber.

Abbildung 3.5 Eine kompakte und eine erweiterbare Fotokamera

Erweiterbarkeit eines Moduls

Auch Softwaremodule können so konstruiert werden, dass sie anpassbarbleiben, ohne auseinander gebaut werden zu müssen. Man muss sie nurmit den »Bajonettanschlüssen« an den richtigen Stellen ausstatten. EinModul muss also erweiterbar gemacht werden.

Eine Kompaktkamera ist für einen Einsatzbereich konstruiert und optimiert. Sie ist einfach, aber nicht erweiterbar.

Eine Spiegelreflexkamera besitzt eingebaute Erweiterungspunkte, an denen man bestimmte Kompo-nenten anschließen kann.


52


Das Modul kann so strukturiert werden, dass die Funktionalität, die füreine Variante spezifisch ist, sich durch eine andere Funktionalität leichtersetzen lässt. Die Funktionalität der Standardvariante muss dabei nichtunbedingt in ein separates Modul ausgelagert werden – genauso wie daseingebaute Blitzgerät nicht stört, wenn man ein externes anschließt.

Die Erweiterbarkeit eines Moduls lässt sich mit dem Prinzip Offen fürErweiterung, geschlossen für Änderung ausdrücken.

DefinierteErweiterungs-

punkte

Wir müssen hier allerdings einschränken: Ein nichttriviales Modul wirdnie in Bezug auf seine gesamte Funktionalität offen für Erweiterungensein. Auch bei einer Spiegelreflexkamera ist es nicht möglich, denBildsensor auszuwechseln. Stattdessen werden einem Modul definierteErweiterungspunkte zugeordnet, über die Varianten des Moduls erstelltwerden können.

Indirektion Solche Erweiterungspunkte können Sie in der Regel durch das Hinzufü-gen einer Indirektion erstellen. Das Modul darf die variantenspezifischeFunktionalität nicht direkt aufrufen. Stattdessen muss das Modul eineStelle konsultieren, die bestimmt, ob die Standardimplementierung oderein Erweiterungsmodul aufgerufen werden soll.

Funktionalitäterkennen

Wie erkennen Sie nun, welche Funktionalität für alle Varianten gleichund welche für die jeweiligen Varianten spezifisch ist? Wo sollen dieErweiterungspunkte hin?

Am einfachsten lässt sich diese Frage beantworten, wenn das Modul nurinnerhalb einer Anwendung verwendet oder nur von einem Team entwi-ckelt wird. In diesem Fall können Sie einfach abwarten, bis der Bedarf füreine Erweiterung entsteht. Wenn der Bedarf da ist, sehen Sie bereits,welche Funktionalität allen Verwendungsvarianten gemeinsam ist und inwelchen Varianten sie erweitert werden muss. Erst dann müssen Sie das

Offen für Erweiterung, geschlossen für Änderung (Open-Closed-Principle)

Ein Modul soll für Erweiterungen offen sein.Das bedeutet, dass sich durch die Verwendung des Moduls zusammen mitErweiterungsmodulen die ursprüngliche Funktionalität des Moduls anpassenlässt. Dabei enthalten die Erweiterungsmodule nur die Abweichungen dergewünschten von der ursprünglichen Funktionalität.

Ein Modul soll für Änderungen geschlossen sein.Das bedeutet, dass keine Änderungen des Moduls nötig sind, um es erweiternzu können. Das Modul soll also definierte Erweiterungspunkte bieten, an diesich die Erweiterungsmodule anknüpfen lassen.


53

Prinzip 5: Trennung der Schnittstelle von der Implementierung 3.5

Modul anpassen und es um die benötigten Erweiterungspunkte berei-chern.

Diese Vorgehensweise ist natürlich nicht möglich, wenn das ursprüngli-che Modul von einem anderen Team entwickelt wird und das Team, wel-ches das Modul erweitern möchte, das ursprüngliche Modul nichtändern kann, um die benötigten Erweiterungspunkte hinzuzufügen. Indiesem Fall ist es notwendig, die benötigten Erweiterungspunkte bereitsim Vorfeld einzugrenzen.

Aufwand durch Erweiterungs-punkte

Das Hinzufügen der Erweiterungspunkte ist mit Aufwand verbunden,der durch die Wiederverwendung der gemeinsamen Funktionalität wett-gemacht werden soll. Wenn die Komponente nicht mehrfach verwendetwird, muss sie auch nicht mehrfach verwendbar sein, und Sie könnensich den Aufwand für das Erstellen von Erweiterungspunkten sparen.

Zu viele nicht genutzte Erweiterungspunkte machen Module unnötigkomplex, zu wenige machen sie zu unflexibel. Die Bestimmung der not-wendigen und sinnvollen Erweiterungspunkte ist deshalb oft nur auf derGrundlage von Erfahrung und Kenntnis des Anwendungskontexts mög-lich.

3.5 Prinzip 5: Trennung der Schnittstelle von der Implementierung

Der Zusammenhang zwischen der Spezifikation der Schnittstelle einesModuls und der Implementierung sollte nur für die Erstellung desModuls selbst eine Rolle spielen. Alle anderen Module sollten die Detailsder Implementierung ignorieren.

Schnittstelle ist Spezifikation

In der obigen Definition dürfen Sie unter dem Begriff Schnittstelle nichtnur bereitgestellte Funktionen und deren Parameter verstehen. DerBegriff Schnittstelle bezieht sich vielmehr auf die komplette Spezifika-tion, die festlegt, welche Funktionalität ein Modul anbietet.

Trennung der Schnittstelle von der Implementierung (Program to interfaces)

Jede Abhängigkeit zwischen zwei Modulen sollte explizit formuliert und doku-mentiert sein. Ein Modul sollte immer von einer klar definierten Schnittstelledes anderen Moduls abhängig sein und nicht von der Art der Implementierungder Schnittstelle. Die Schnittstelle eines Moduls sollte getrennt von der Imple-mentierung betrachtet werden können.


54


Durch das Befolgen des Prinzips der Trennung der Schnittstelle von der Im-plementierung wird es möglich, Module auszutauschen, welche dieSchnittstelle implementieren. Das Prinzip ist auch unter der Formulie-rung Programmiere gegen Schnittstellen, nicht gegen Implementierungenbekannt.

Protokoll-ausgaben

Nehmen Sie als ein einfaches Beispiel ein Modul, das für die Ausgabevon Fehler- und Protokollmeldungen zuständig ist. Unsere Implementie-rung gibt die Meldungen einfach über die Standardausgabe auf dem Bild-schirm als Text aus.

Wenn andere Module, die diese Funktionalität nutzen, sich darauf ver-lassen, dass die Fehlermeldungen über die Standardausgabe auf demBildschirm erscheinen, kann das zu zweierlei Problemen führen. Pro-bleme treten z.B. dann auf, wenn Sie das Protokollmodul so ändernmöchten, dass die Meldungen in einer Datenbank gespeichert oder perE-Mail verschickt werden. In Abbildung 3.6 ist das Problem illustriert.

Abbildung 3.6 Trennung der Schnittstelle von der Implementierung

LOG

Protokolldatenwerden auf demBildschirmausgegeben

Bildschirmausgabe

Datenbank

protokollieren

Modul 1 Modul 2

Auswertungsmodul 1

Protokolldatenbereitstellen

Auswertungsmodul 2

!

!

Man sollte nicht wissenmüssen, wie das Modul LOG

die Fehlermeldungenbehandelt.

Protokoll-daten werden auf dem Bildschirm ausgegeben


55

Prinzip 5: Trennung der Schnittstelle von der Implementierung 3.5

Problem 1: Funktionalität nicht genutzt

Dieses Problem kann daraus resultieren, dass andere Module die bereit-gestellte Funktionalität gar nicht nutzen, sondern eine äquivalente Funk-tionalität selbst implementieren. Es ist doch so einfach, eine Meldungüber die Standardausgabe auszugeben. Jedes »Hello World«-Programmmacht es, warum also ein spezielles Protokollmodul nutzen? Ersetzen Siejetzt das Protokollmodul durch ein anderes, das die Meldungen in einerDatenbank speichert, werden bestimmte Meldungen tatsächlich in derDatenbank landen, andere dagegen immer noch auf der Standardausgabeerscheinen. Dieses Problem haben wir bereits in Abschnitt 3.3 angespro-chen.

Problem 2: Sich auf die Implementierung verlassen

Ein anderes Problem kann für die Module entstehen, welche die Fehler-meldungen einlesen und auswerten. Wenn sich diese Module darauf ver-lassen, dass die Fehlermeldungen über die Standardausgabe ausgegebenwerden, können sie z.B. die Umleitung der Standardausgabe dafür nut-zen, um die Meldungen einzulesen. Werden die Meldungen nicht mehrüber die Standardausgabe ausgegeben, werden die abhängigen Modulenicht mehr funktionieren.

Sie können die geschilderten Probleme vermeiden, indem Sie sich inIhren Modulen nur auf die Definition der Schnittstelle anderer Moduleverlassen. Dabei müssen diese jeweils ihre Schnittstelle möglichst klardefinieren und dokumentieren.

Verwendung von Schriftgrößen

Ein anderes Beispiel der Probleme, die sich daraus ergeben, wenn mansich statt der Schnittstelle auf deren konkrete Implementierung verlässt,lässt sich leider viel zu oft beobachten, wenn Sie unter Windows die Bild-schirmauflösung und die Größe der Fonts ändern. Zu viele Anwendun-gen gehen davon aus, dass die Bildschirmauflösung 96 dpi beträgt (KleineSchriftarten), ändert man die Auflösung auf Große Schriftarten (120 dpi),sehen sie merkwürdig aus oder lassen sich gar nicht mehr benutzen.

Das Problem besteht darin, dass sich die Anwendungen auf einebestimmte Implementierung der Darstellung der Texte auf dem Bild-schirm verlassen. Sie verlassen sich darauf, dass für einen bestimmtenText ein Bereich des Bildschirms von bestimmter Größe gebraucht wird.Dies ist jedoch nur ein nicht versprochenes Detail der Implementierung,nicht eine in der Schnittstelle der Textdarstellung unter Windows defi-nierte Funktionalität.

Vorsicht: Java- und C#-Interfaces

Die Programmiersprachen Java und C# bietet in ihren Konstrukten eineTrennung zwischen Klassen und Schnittstellen (Interfaces). Sie könntennun annehmen, dass Sie das Prinzip schon dann erfüllen, wenn Sie in


56


Ihren Modulen vorrangig mit Java- oder C#-Schnittstellen anstelle vonkonkreten Klassen arbeiten. Dies ist aber nicht so. Das Prinzip beziehtsich vielmehr darauf, dass Sie keine Annahmen über die konkreten Im-plementierungen machen dürfen, die hinter einer Schnittstelle liegen.Diese Annahmen können Sie aber bei Java- und C#-Interfaces genausomachen wie bei anderen Klassen.

3.6 Prinzip 6: Umkehr der Abhängigkeiten

Eine Möglichkeit, einer komplexen Aufgabe Herr zu werden, ist es, sie ineinfachere Teilaufgaben aufzuteilen und diese nach und nach zu lösen.Ähnlich können Sie auch bei der Entwicklung von Softwaremodulen vor-gehen. Sie können Module für bestimmte Grundfunktionen erstellen,die von den spezifischeren Modulen verwendet werden.

Aber ein Entwurf, der grundsätzlich von Modulen ausgeht, die andereModule verwenden (Top-down-Entwurf), ist nicht ideal, weil dadurchunnötige Abhängigkeiten entstehen können. Um die Abhängigkeiten zwi-schen Modulen gering zu halten, sollten Sie Abstraktionen verwenden.

Unter Verwendung von Abstraktionen können wir nun das Prinzip derUmkehr der Abhängigkeiten formulieren.

Abstraktion

Eine Abstraktion beschreibt das in einem gewählten Kontext Wesentlicheeines Gegenstand oder eines Begriffs. Durch eine Abstraktion werden dieDetails ausgeblendet, die für eine bestimmte Betrachtungsweise nicht relevantsind. Abstraktionen ermöglichen es, unterschiedliche Elemente zusammenzu-fassen, die unter einem bestimmten Gesichtspunkt gleich sind.

So lassen sich zum Beispiel die gemeinsamen Eigenschaften von verschiedenenBetriebssystemen als Abstraktion betrachten: Wir lassen die Details der spezi-fischen Umsetzungen und spezielle Fähigkeiten der einzelnen Systeme wegund konzentrieren uns auf die gemeinsamen Fähigkeiten der Systeme. Einesolche Abstraktion beschreibt die Gemeinsamkeiten von konkreten Betriebs-systemen wie Windows, Linux, SunOS oder Mac OS.

Umkehr der Abhängigkeiten (Dependency Inversion Principle)

Unser Entwurf soll sich auf Abstraktionen stützen. Er soll sich nicht auf Spezia-lisierungen stützen.


57

Prinzip 6: Umkehr der Abhängigkeiten 3.6

Softwaremodule stehen in der Regel in einer wechselseitigen Nutzungs-beziehung. Bei der Betrachtung von zwei Modulen können Sie diese alsoin ein nutzendes Modul und in ein genutztes Modul einteilen.

Definition:Abstraktion

Das Prinzip der Umkehr der Abhängigkeiten besagt nun, dass die nutzen-den Module sich nicht auf eine Konkretisierung der genutzten Modulestützen sollen. Stattdessen sollen sie mit Abstraktionen dieser Modulearbeiten. Damit wird die direkte Abhängigkeit zwischen den Modulenaufgehoben. Beide Module sind nur noch von der gewählten Abstraktionabhängig. Der Name Umkehr der Abhängigkeiten ist dabei etwas irrefüh-rend, er deutet an, dass Sie eine bestehende Abhängigkeit einfach umdre-hen. Vielmehr ist es aber so, dass Sie eine Abstraktion schaffen, von derbeide beteiligte Module nun abhängig sind. Die Abhängigkeit von derAbstraktion schränkt uns aber wesentlich weniger ein als die Abhängig-keit von Konkretisierungen.

Weg vom Top-down-Entwurf

Die Methode geht damit weg von einem Top-down-Entwurf, bei dem Siein einem nutzenden Modul einfach dessen benötigte Module identifizie-ren und diese in der konkreten benötigten Ausprägung einfügen. Viel-mehr betrachten Sie auch die genutzten Module und versuchen, für sieeine gemeinsame Abstraktion zu finden, die das minimal Notwendigeder genutzten Module extrahiert.

Doch auch wenn dieser Abschnitt die Wichtigkeit der Abstraktionbeschreibt, sollten wir konkret werden und an einem Beispiel illustrie-ren, was Umkehr der Abhängigkeiten in der Praxis bedeutet.

Nehmen wir an, Sie möchten eine Windows-Anwendung erstellen, dieaus dem Internet die aktuelle Wettervorhersage einliest und sie grafischdarstellt. Den Prinzipien der einzigen Verantwortung und der Trennung derAnliegen folgend, verlagern Sie die Funktionalität, die sich um dieBehandlung der Windows-API kümmert, in eine separate Bibliothek.Vielleicht können Sie sogar eine bereits vorhandene Bibliothek wie dieMFC4 einsetzen.

Schauen wir uns in der Abbildung 3.7 die resultierenden Abhängigkeitenvon einigen Modulen unserer Anwendung an.

4 MFC – Microsoft Foundation Classes – eine C++ Bibliothek, die neben anderer Funk-tionalität die Windows-API in einer objektorientierten Form bereitstellt.


58


Abbildung 3.7 Abhängigkeiten in unserer Beispielanwendung

Das sieht schon nicht unvernünftig aus. Das Modul für die Darstellungder Wetterdaten ist von dem Windows API-Modul abhängig, dieses abernicht von der Darstellung der Wetterdaten. Das bedeutet, dass das Win-dows API-Modul auch in anderen Anwendungen, die nichts mit demWetter zu tun haben, eingesetzt werden kann.

Doch mit einem Problem kommt diese Modulstruktur leider sehr schwerzurecht: Sie können Ihre Anwendung nur unter Windows laufen lassen.Auf dem Mac oder unter Linux oder Unix kann die Anwendung nichtohne weiteres laufen.

Sie könnten sicherlich ein anderes Modul für die Mac API schreiben undwieder ein anderes für Linux oder Unix. Aber leider bedeutet das, dass Sieauch das Modul für die Darstellung der Wetterdaten anpassen müssen.

Abstraktes Modul Damit dieses Modul aber von dem verwendeten Betriebssystem unab-hängig werden kann, müssen Sie eine Abstraktion der verschiedenenBetriebssysteme als ein neues abstraktes Modul definieren. Die verschie-denen betriebssystemabhängigen Module werden die spezifizierte Funk-tionalität bereitstellen.

Bei einem Top-down-Design wie in der Abbildung 3.7, sind die Modulevon den Modulen abhängig, deren Funktionalität sie nutzen. DieModule, welche die Funktionalität bereitstellen, sind von ihren Client-Modulen unabhängig.

Durch das Einführen eines abstrakten Betriebssystemmoduls ändert sichdies. Die Abstraktion schreibt vor, welche Funktionalität die konkretenImplementierungen bereitstellen müssen. Die Abstraktion ist dabei vonden Implementierungen unabhängig. Man muss sie nicht ändern, wennman eine neue Implementierung, sagen wir für Amiga, erstellt. Jede Im-plementierung ist allerdings abhängig von der abstrakten Spezifikation.Ändert sich die Spezifikation, müssen alle ihre Implementierungen ange-passt werden. Die Abhängigkeit verläuft also in »umgekehrter« Richtung– vom Bereitsteller, nicht zu ihm. Daher auch der Name Umkehr derAbhängigkeiten.

Darstellung der Wetterdaten

Windows-API- Modul

HTTP-Modulnutzt

nutzt


59


Portables DesignAbbildung 3.8 zeigt ein neues, portableres Design, in dem die Mehrfach-verwendbarkeit des Moduls für die Darstellung der Wetterdaten verbes-sert wurde.

Abstraktion, Abhängigkeiten und die Änderungen

Wenn Sie sich das Beispiel genauer anschauen, stellen Sie fest, dass indiesem Design die abstrakten Module nur »eingehende« Abhängigkeiten(also andere Module von ihnen abhängig sind) und die konkretenModule nur »ausgehende« Abhängigkeiten haben – sie sind also vonanderen Modulen abhängig. Da man davon ausgehen kann, dass die abs-trakten Spezifikationen seltener als die konkreten Implementierungengeändert werden müssen, ist unser neues Design auf die Änderungswün-sche der Anwender gut vorbereitet.

Abbildung 3.8 Beispielanwendung mit »umgekehrten« Abhängigkeiten

Die häufigsten Änderungen werden in Modulen stattfinden, von denenkein anderes Modul abhängig ist. Die Änderungen werden sich also sel-tener in andere Module »fortpflanzen«. In der Praxis sind Module seltenganz abstrakt oder ganz konkret. Die meisten enthalten zum Teil kon-krete Implementierungen und zum Teil abstrakte Deklarationen. EinQualitätskriterium für das Design ist der Zusammenhang zwischen derAbstraktheit eines Moduls und dem Verhältnis zwischen seinen ein- undausgehenden Abhängigkeiten. Je abstrakter ein Modul, desto größersollte der Anteil der eingehenden Abhängigkeiten sein.

Abbildung 3.9 zeigt dasselbe Design noch einmal, allerdings etwasanders dargestellt. Diesmal verlaufen alle Abhängigkeiten in der Darstel-

Darstellung derWetterdaten

Betriebssystem-abstraktion

Datenbeschaffungs-abstraktion

Windows-API-Modul

HTTP-Modul

Datenbankmodul

Mac-API-Modul

Richtung der Abhängigkeit

Fortpflanzung der Änderungen

konkrete Implementierungennutzende Module

abstrakte Zwischenschicht konkrete Implementierungengenutzte Module



»Umgekehrte« Abhängigkeiten

stellt bereit

stellt bereit

stellt bereit

stellt bereit

nutzt

nutzt


60


lung in dieselbe Richtung. Und wir können zufrieden feststellen, dass dieAbhängigkeiten alle von den konkreten zu den abstrakten Modulen ver-laufen.

Abbildung 3.9 Konkrete Module sollen von abstrakten Modulen abhängig sein.

3.6.1 Umkehrung des KontrollflussesAchtung: Dies istnicht Hollywood!

Durch die Umkehrung der Abhängigkeiten kann bei der Umsetzung ineiner Anwendung auch die sogenannte Umkehrung des Kontrollflusses(engl. Inversion of Control) resultieren. Umkehrung der Abhängigkeiten undUmkehrung des Kontrollflusses dürfen allerdings nicht verwechselt werden.

Darstellung der Wetterdaten

Betriebssystem- abstraktion

Datenbeschaffungs- abstraktion

Windows-API- Modul

HTTP-Modul

Datenbankmodul

Mac-API-Modul stellt bereit

stellt bereit

stellt bereit stellt bereit

nutzt

nutzt



Konkrete Implementierungen Abstraktionen

Umkehrung des Kontrollflusses (engl. Inversion of Control)

Als die Umkehrung des Kontrollflusses wird ein Vorgehen bezeichnet, bei demein spezifisches Modul von einem mehrfach verwendbaren Modul aufgerufenwird. Die Umkehrung des Kontrollflusses wird auch Hollywood-Prinzipgenannt: »Don’t call us, we’ll call you«.

Die Umkehrung des Kontrollflusses wird eingesetzt, wenn die Behandlung vonEreignissen in einem mehrfach verwendbaren Modul bereitgestellt werdensoll. Das mehrfach verwendbare Modul übernimmt die Aufgabe, die anwen-dungsspezifischen Module aufzurufen, wenn bestimmte Ereignisse stattfinden.Die spezifischen Module rufen also die mehrfach verwendbaren Module nichtauf, sie werden stattdessen von ihnen aufgerufen.


61


Betrachten wir die Umkehrung des Kontrollflusses an dem in Abbildung3.10 dargestellten Beispiel.

Das Beispiel stellt die Struktur einer Anwendung vor, die Wahlergeb-nisse visualisiert. Sie verwendet eine Bibliothek, die schöne Balken- undKuchendiagramme erstellen kann. Das anwendungsspezifische ModulWahlvisualisierung ruft diese Grafikbibliothek auf – dies ist der »normale«Kontrollfluss: Die Bibliothek bietet eine Schnittstelle an, die von spezifi-schen Modulen aufgerufen werden kann.

Abbildung 3.10 Umkehrung des Kontrollflusses

Unsere Anwendung zur Visualisierung von Wahlergebnissen ist aberauch eine Windows-Anwendung, die auf der Basis eines mehrfach ver-wendbaren Frameworks5 gebaut wurde. Das Windows-Framework über-nimmt z.B. die Aufgabe, das Modul Wahlvisualisierung zu informieren,falls ein Fenster vergrößert wurde und die Grafik angepasst werdenmuss. Dies ist der »umgekehrte« Kontrollfluss: Das Framework gibt eineSchnittstelle vor, die von den spezifischen eingebetteten Modulen imple-mentiert werden muss. Diese Schnittstelle wird anschließend vom Fra-mework aufgerufen.

5 Frameworks sind Anwendungsbausteine, die einen allgemeinen Rahmen für jeweilsspezifische konkrete Anwendungen zur Verfügung stellen. Die Umkehrung des Kon-trollflusses ist der zentrale Mechanismus, der von den meisten Frameworks genutztwird. In Kapitel 8, »Module und Architektur«, werden Sie die Eigenschaften von Fra-meworks anhand einiger Beispiele kennen lernen.

Grafikbibliothek ruft auf Wahlvisualisierung

Windows Framework

ruft a

uf

»normaler« Kontrollfluss

»umgekehrter«Kontrollfluss

anwendungsspezifisch mehrfach verwendbar


62


Sie werden eine spezielle Form der Umkehrung des Kontrollflusses, diesogenannte Dependency Injection, in Abschnitt 7.2.7 kennen lernen.

3.7 Prinzip 7: Mach es testbar

PKW-Motoren brauchen Öl, damit sie funktionieren. Sie benötigen aberkeinen Ölmessstab. Und doch werden alle PKW-Motoren mit einemÖlmessstab ausgeliefert, und niemand zweifelt am Sinn dieser Konstruk-tion. Autos sind auch ohne einen Ölmessstab fahrtüchtig, und wenn keinÖl mehr da ist, kann man das auch auf anderem Wege feststellen.

Doch der Ölmessstab hat einen großen Vorteil: Er ermöglicht uns, eineKomponente des Motors, den Ölpegel, separat von anderen Komponen-ten zu überprüfen. Und so können wir, wenn das Auto streikt, schnellerkennen, dass wir zu wenig Öl haben; noch bevor wir die Zündkerzenunnötigerweise ausgebaut und überprüft haben.

Software ist eine komplexe Angelegenheit, bei deren Erstellung Fehlerpassieren. Es ist sehr wichtig, diese Fehler schnell zu entdecken, sieschnell zu lokalisieren. Deswegen ist es sehr wertvoll, wenn sich die ein-zelnen Komponenten der Software separat testen lassen.

Genau wie bei der Konstruktion der Motoren werden auch in der Soft-wareentwicklung manche Designentscheidungen getroffen, nicht um dieFunktionalität der Software zu verbessern oder um eine Komponentemehrfach verwendbar zu machen, sondern um sie testbar zu machen.

Die moderneren Autos mit einem Bordcomputer überprüfen denÖlstand automatisch. Das ist sehr bequem. Man braucht den Ölmessstabnur dann zu benutzen, wenn der Bordcomputer ein Problem meldet.

Auch in der Softwareentwicklung kann man vieles automatisch testenlassen, und erst wenn die Tests ein Problem melden, muss man sichselbst auf Fehlerjagd begeben.

Die populärsten automatisierten Tests sind die Unit-Tests.

Unit-Tests

Ein Unit-Test ist ein Stück eines Testprogramms, das die Umsetzung einerAnforderung an eine Softwarekomponente überprüft. Die Unit-Tests könnenautomatisiert beim Bauen von Software laufen und so helfen, Fehler schnell zuerkennen.


63

Prinzip 7: Mach es testbar 3.7

Schwierige TestsIdealerweise werden für jede angeforderte Funktionalität einer Kompo-nente entsprechende Unit-Tests programmiert. Idealerweise. Wir lebenaber nicht in einer idealen Welt, und manche Komponenten automati-siert zu testen ist schwierig. Wie soll man z.B. automatisiert testen, dasseine Eingabemaske korrekt dargestellt wurde? Soll man einen Schnapp-schuss des Bildschirmes machen und ihn mit einer vorbereiteten Bild-datei vergleichen? Was passiert, wenn der Entwickler seine Bildschirm-einstellungen ändert? Wie testet man, dass die Datenbank korrekt mani-puliert wurde? Muss man die Daten jederzeit zurücksetzen? Das dauertaber sehr lange.

Das Programmieren guter Unit-Tests ist nicht leicht. Es kann sogar vielaufwändiger als die Implementierung der zu testenden Funktionalitätselbst sein. Es kann aber auch nicht Sinn der Sache sein, die Komplexitätder entwickelten Anwendung niedrig zu halten, dafür aber die Komple-xität des Tests explodieren zu lassen.

Stattdessen versucht man, die Gesamtkomplexität der Entwicklung zureduzieren. Und das führt häufig dazu, dass die Module auch wegenihrer Testbarkeit getrennt werden.

So kann man die Komponente, die eine Eingabemaske bereitstellt, inzwei Teile trennen. In Teil 1 werden die Eigenschaften der dargestelltenSteuerelemente vorbereitet, ohne auf ihre tatsächliche Darstellung ach-ten zu müssen. So kann man leicht automatisiert überprüfen, ob z.B. dasEingabefeld name gesperrt und die Taste löschen aktiviert ist. In eineranderen Komponente 2 werden dann die jeweiligen betriebssystemspe-zifischen Steuerelemente programmiert – diese können manuell getestetwerden, ihre Implementierung wird sich nicht so häufig ändern.

Mock-ObjekteOder man trennt die Bearbeitungslogik von der Anbindung an eine kon-krete Datenbank. Dann kann man sie statt mit der langsamen Datenbanklieber mit einer sehr schnellen Ersatzdatenbank testen. Die Ersatzdaten-bank braucht keine wirkliche Datenbank zu sein, es reicht, wenn sie diefür den Test geforderte Funktionalität liefert. Solche Ersatzkomponen-ten, die nur zum Testen anderer Komponenten existieren, werden Mock-Objekte genannt.

Auswirkungen auf das Design

Erkennen Sie, wohin das führt? Sie trennen die Komponenten, nur umsie leichter testbar zu machen, und plötzlich stellen Sie fest, dass sie nichtmehr von der konkreten Implementierung anderer Komponentenabhängig sind, sondern von Abstraktionen mit einer kleinen Schnitt-stelle.


64


Das Streben nach Verringerung der Gesamtkomplexität der Entwicklung,der entwickelten Komponenten und der Tests führt dazu, dass die Ver-wendbarkeit der Komponenten erleichtert wird. Die Schwierigkeiten,bestimmte Tests zu entwickeln, zeigen Ihnen, wo Sie mehr Abstraktio-nen brauchen, wo Sie die Umkehr der Abhängigkeiten einsetzen können,wo Sie eine Schnittstelle explizit formulieren müssen und wo Sie Erwei-terungspunkte einbauen sollten.

Durch die konsequente Erstellung der Unit-Tests wird also nicht nur dieKorrektheit der Software sichergestellt, sondern auch das Design derSoftware verbessert.


645

Index

A

Abarbeitungsreihenfolge, für Sammlung von Objekten festlegen 452

Abgeleitete Klassen arbeiten nicht mehr? 229

Abhängigkeitimplizit 48, 49sichtbar machen 45zwischen Modulen und Klassen aufheben

387Ablauf 337

Beschreibung 412Ablaufsteuerung 506Abstract Windowing Toolkit 566Abstrakte Fabrik 355

Definition 357Verwendung 357

Abstrakte Klassen 167, 170in C++ 174in Java und C# 174Umsetzung 173

Abstrakte Methoden 170Abstraktion 56

Definition 56Accept Event Action 415action-mappings 521Advice, Definition 543Aggregate 129Aggregation 119, 129

Definition 129UML 130

Ajax 586Aktion, Sichtweisen 412Aktivitätsbereich 414Aktivitätsdiagramm 412, 413Alternativschlüssel 305Analysemodell 86Änderungen an Basisklassen und

Schnittstellen 229Anforderung, Änderung 42Anliegen 45

durch ein Modul repräsentieren 45in einem Modul 530in unterschiedlichen Modulen 47

Trennung 46übergreifend 530

Anmerkung � AnnotationAnnotation 562

@Override 565@SuppressWarnings 565Definition 565vordefiniert 565

Anonyme Klassen 208Java 438

Anwendungscontainer 539Anwendungsfalldiagramm 412Anwendungsrahmen 506AspectJ 22, 547Aspekt, Definition 543Aspekte 527Aspektorientierte Frameworks 540Aspektorientierter Observer 560Aspektorientiertes Programmieren 539Aspektorientierung, Anwendung 550Assoziation 117

Formen 118in UML 119Richtung 119Rollen 119

Assoziationsklasse 127Assoziationsklassen, UML 127Asynchrone Nachricht 419Attribute 68, 132Aufzählung

Elemente mit Methoden 141typsicher und serialisierbar 145

Aufzählungen 140als abgegrenzte Mengen von Objekten

140Ausnahme � ExceptionAutomatische Speicherbereinigung �

Garbage CollectionAWT 566

B

Basisklasseninstabil 249Kopplung mit abgeleiteter Klasse 250


646

Index

Benutzerfreundlichkeit 24Beobachter-Muster

mit Aspektorientierung umsetzen 560MVC 512

Beziehungals Assoziation, Komposition,

Aggregation? 132Attribute 126beidseitig navigierbar 128Einschränkungen in UML 124einwertig 128Implementierung 128in relationaler Datenbank abbilden 311Klassen und Objekte 117mehrwertig 123, 124, 128Navigierbarkeit 120Richtung 119Umsetzung 128zwischen Objekt und Teilen 119

Beziehung � AssoziationBeziehungsklasse 126, 127

UML 126Boyce-Codd-Normalform 329

C

C# 629Methoden überschreiben 249partielle Klasse 377Sichtbarkeitsstufen 112Typisierung 100

C++ 623Compiler 626Klassen als Module 104Methoden überschreiben 248späte Bindung 228Struktur 623Syntax 624Typisierung 100, 101

C++-Konstruktoren, Polymorphie 238Cascading Stylesheets 591Chain of Responsibility 367Checked Exception 491

als Unchecked Exception weiterreichen 498

Umgang 493Class Table Inheritance 319Clone-Operation 446

Java 447

CLOS 632Struktur 633Syntax 633

Code Scattering, Definition 530Code Smell 488Code Tangling, Definition 530Code-Durcheinander � Code TanglingCode-Redundanz

vermeiden durch Vererbung 244vermeiden mittels Fabrik 355

Code-Streuung � Code ScatteringCollection � SammlungCommon Lisp Object System 632Composite Pattern � Entwurfsmuster,

KompositumConcrete Table Inheritance 318Constructor Call 545Constructor Execution 545Constructor Injection 395Container 539

Definition 509Komplexitäten abbauen 392

Controller in MVC, Definition 514Copy-Konstruktor 341

Java 444Crosscutting

dynamisch 541statisch 541

Crosscutting Concern 541Definition 530implementieren 541in Klassen einarbeiten 541

CSS 591

D

Daten 28Typen 29

Datenbankidentität 150Datenelemente, Zugriff 546Datenkapselung 31, 67, 68

Bedeutung 71Nachteile 73

Datenmodellin dritte Normalform bringen 326in zweite Normalform überführen 324

Datensatz 303Datenstruktur, definieren 49Datentypen 92


647

Index

Delegaten-Klassen 440Definition 439

Delegationals Alternative zu Vererbung 249, 268Definition 269

Delphi, Typisierung 101Demeter-Prinzip

Nutzen 208Verletzung 208

Denormalisierung 321Dependency Injection 386, 387, 510

Beispiel in PHP5 604Einsatz 396Übergabe 394Varianten 394

Dependency Inversion Principle � Prinzip Umkehr der Abhängigkeiten

Design by Contract 556Designmodell 86Design-Patterns � EntwurfsmusterDiamantenregel 282Diensteverzeichnis, Definition 396Dispatcher 199Don't repeat yourself 47Double-checked Locking 381Downcast 180Dritte Normalform 326Ducktyping 95Dynamisch typisierte

Programmiersprachen, rein spezifizierende 170

Dynamische Klassifizierung 289Dynamische Pointcuts 554Dynamische Typisierung 95Dynamischer Speicher 397Dynamisches Crosscutting 541Dynamisches Typsystem 94

E

Eigenschaft eines Objekts 67Einfache Klassifizierung 86Eingabe-Controller 515Einweben 541Einwertige Beziehung 128Enterprise Java Beans 151Entity Beans 152, 154Entity-Relationship-Darstellung 312

Entwurfsmuster 19Abstrakte Fabrik 349Beobachtetes-Beobachter 263, 512Besucher 223Fliegengewicht 134, 137Kompositum 227Prototyp 348Schablonenmethode 245Strategie 294, 506

Enumerations 140Ereignis 421Ersatzkomponente 63Ersetzbarkeit 276

Unterklassen 457Erweiterung, Module 505Erweiterungsmodul 52Erweiterungspunkt 52, 505

bestimmen 507hinzufügen 53

Eventhandler 421, 433Definition 435

Exception 471, 472Ausführungspfade 480Einsatz 475Kontrakte formulieren 489Kontrollfluss eines Programms 478Teil eines Kontrakts 488vs. Fehlercode 477werfen 472

Exception Handling 480Exception Safety 479Exception-Sicherheit 479Exemplar 84Exemplare einer Klasse

erzeugen 113verwalten 113

Exposed Joinpoints 544

F

Fabrik 349abstrakt 355Beispiel in PHP5 603Definition 349für Module unsichtbar machen 387Konfigurierbar 360Schnittstelle 357über Datei konfigurieren 361


648

Index

Fabrikmethode 368Anwendung 372Bedingung 372Definition 349Eigenschaften 371Unterschied abstrakte Fabrik 371

Factory Pattern 350Fehlercode 477Fehlersituation, Bekannt 489field access 546Finale Klassen 249Flache Kopie 449Fliegengewicht-Entwurfsmuster 138Flyweight 138Fragile Base Class Problem 250Fragile Binary Interface Problem 228Framework 53, 506Fremdschlüssel 306Function Objects � FunktionsobjekteFünfte Normalform 332Funktion 302

Definition 29Funktionale Abhängigkeit 304Funktionalität

Abweichungen festhalten 52umsetzen 48zwangsweise nutzen 244

Funktionsobjekte 421, 433Definition 436

G

Garbage Collection 399Arten 400Lebensdauer von Objekten 409Umsetzung 400Varianten 399

Geerbte Methode, überschreiben 565Generalisierung 156Generat 534Generator 421

C# 431Java 430Problem 430Zweck 422

Generator als Methode 430Generics 98Generierter Code 534

Geschachtelte Klassen 191in C# und C++ 192Java 191

Geschützt innerhalb des Packages 111Geschützte Datenelemente, Zugriff 184Gleichheit 254

Eigenschaften 255prüfen 254prüfen in Java 255

Gleichheitsprüfungbei Vererbungsbeziehung 255Formale Kriterien 255

Globale Variable und Singleton 385

H

Heap 398Hibernate 537Hierarchie von Klassen

virtuelle-Methoden-Tabelle 230

I

Identität 81, 133, 147, 151Implementierung 53

Beziehungen 128vererben 239

Implementierungen, Aufrufen 243Implizite Abhängigkeit 48, 49Indirektion 52inner classes 191Instabile Basisklassen 249Instance � ExemplarInteraktionsübersichtsdiagramm 413Interface Injection 395

Nachteil 395Interface � Schnittstellen-KlasseInterzeptor

Definition 542Implementierung 542

Introduction 549, 559Warnungen 550

Introspektion 538Invariante 90Inversion of Control 60Iterator 424

Definition 187, 425dynamisch 425


649

Index

J

Jakarta Struts 519Java 626

finale statische Variable 146Generator 430geschachtelte Klassen 191Identität von Objekten 152Klassen als Module 102Methoden überschreiben 248Protokolle 351Sichtbarkeitsstufen 111Struktur 626Syntax 627Typisierung 99virtuelle Machine (Garbage Collection)

409JavaScript 77, 629

Erweiterung von Objekten 345Funktionen 343Hierarchie von Prototypen 345Klassen 342Objekt erzeugen 342Struktur 630Syntax 631Typisierung 100Vererbung 345Vererbungskette 347

JavaScript Object Notation � JSONJDBC 369Joinpoint

Arten 544Aufruf einer Operation 545Ausführung einer Methode 545Ausführung eines Konstruktors 545Definition 542offen gelegt 544Zugriff auf die Datenelemente 546

jQuery 592JSON 588JUnit 508

K

Kapselung von Daten 31, 68Kardinalität 123Klassen 84, 92, 176

Abstrakt 167als Vorlagen 338Anonym 208

Beziehungen untereinander 117Definition 84Elemente 102erweitern mit Aspektorientierung 559Erzeugung von Exemplaren 545Exemplare erzeugen 113final 249Konformität 160konkret 167Kontrakt 88Kopplung mit Typ 94Methoden und Daten zuordnen 112Modul 102Multiplizität 121Parametrisiert 96Schnittstelle 89Schnittstelle trennen 55Spezifikation 87Spezifikation durch Kontrakt 88spezifizierend 169

Klassen als Module, Java 102Klassen und Typen koppeln 94Klassen von Objekten 133Klassen von Werten 133Klassenbasierte Elemente, Verwendung

113Klassenbasierte Sichtbarkeit 107Klassenbezogene Attribute 112Klassenbezogene Konstanten 115Klassenbezogene Methoden 112

Hilfsfunktionen 114Klassenhierarchie auf relationale

Datenbank abbilden 315Klassenhierarchien anpassen bei

Typsystemen 176Klassenmanipulation durch Aspekte 541Klassenzugehörigkeit dynamisch ändern

290Klassifizierung 289

Definition 85dynamisch 290einfach 86mehrfach 86

Kohäsion maximieren 44Kommunikationsmodul 45Komparator 452Komplexität 22

beherrschen durch Strukturierung 29reduzieren 45, 48


650

Index

Komplexität beherrschen, Prinzipien 39Komposition 119, 129

bei Hierarchie 131Definition 129Einsatz 131UML 130

Konfigurationsdateien 564Konfigurierbare Fabrik 360

in Sprachen ohne Reflexion 363Umsetzung 361Umsetzung in Java 361

Konformität 160Konstante

benannte 48klassenbezogen 115

Konstruktor 338Aufruf 545Ausführung 545Gruppen 339mit Initialisierung 340

Konstruktoraufruf 113Konstruktoren 113Kontrakt 455

Klassen 88, 157Operation 79prüfen 464Prüfung durch Methode 468überprüfen 455Überprüfung mit Aspektorientierung 556von Objekten 79

Kontraktverletzungdurch Programmierfehler 489Exception 484

Kontrollfluss eines Programmsunterbrochen 472verlassen 472

Kontrollfluss, Umkehrung 387Kopie 442

als Prototyp 443Eigenschaften 447flach 449Sammlung 443Tiefe 448und Zyklische Referenz 449

Kopieren aller referenzierten Objekte 406Kopiervorgang, Endlosschleife 449Kopplung minimieren 44Korrektheit 24Kovariante Typen 276

L

Laufzeitpolymorphie 193Laufzeitumgebungen 509Law of Demeter 206Law of leaky Abstractions 228Lazy Initialization 380, 382Leichtgewichtiger Container 392, 510lightweight container 392Link (UML) 119Logging

Lösung mit Aspektorientierung 552

M

Manipulation von Klassen 541Mark and Sweep 400Markieren und Löschen

Problem 406Markieren von referenzierten Objekten

400Mehrfache Klassifizierung 86Mehrfachvererbung 261

Datenstrukturen in C++ 283Datenstrukturen in Python 283Ersetzung durch Komposition 287Operationen und Methoden in Python

280Problemstellung 273von Operationen und Methoden C++ 279

Mehrfachvererbung der Implementierung 262ersetzen in Java und C# 268Problem 265

Mehrfachvererbung der Spezifikation 261Java und C# 275

Mehrfachverwendbarkeit, Modul 43Mehrfachverwendung 138

Vorteil 139Mehrwertige Beziehungen 123Message Driven Beans 152Metainformation 536, 562

Definition 536Metaobjekt, Definition 536method_missing 205Methode

abstrakt 170als Implementierung von Operationen

200


651

Index

anhand von Typ der Objekte bestimmen 210

Aufruf 206Ausführung 545Definition 75für Überschreiben sperren 248Implementierung 75paarweise aufrufen 245Scheitern anzeigen 477überschreiben 241überschrieben 246Ursache für Nichterfüllung der Aufgabe

475Methodenaufruf, verkettet 206Methodenimplementierung, Interface

549Mixin

C++ 273Definition 271mit Klassen verwenden 559Ruby 271

Mock-Objekte 63Model 1 für Webapplikationen 519Model 2 für Webapplikationen 519Modell in MVC, Definition 515Modellierung, der Schnittstelle 182Modellierungsplacebo 131Model-View-Controller � MVCModel-View-Presenter 523Modul 40, 503

Abhängigkeiten 40, 43, 44, 59Änderung 59Änderung vermeiden 51Anforderungen umsetzen 41Anpassungsfähigkeit 50Erweiterbarkeit 51Erweiterung 505Formulierung der Abhängigkeiten 53Identifikation 42Kopplung 44Mehrfachverwendbarkeit 43Schnittstelle 53Testbarkeit 62Verantwortung 40, 41Verwendungsvarianten 52zusammenführen 48Zweck 41

Multiple DispatchEntwurfsmuster Besucher 215, 216

Java 212mit Unterstützung durch die

Programmiersprache 215ohne Unterstützung durch die

Programmiersprache 212Praxisbeispiel 215, 216

Multiplizität 120Darstellung in UML 121Definition 121

MVC 511, 512Ansatz 511Begriffsdefinitionen 514in Webapplikationen 518Testbarkeit 523Ursprung 513

N

Nachbedingung 90Nachricht an Objekte 421Namenskonvention 563Nassi-Shneiderman-Diagramm 31Natürlicher Schlüssel 309Navigierbarkeit 120

UML 120Nebenläufigkeit

Java 380Neustart bei Kontraktverletzung 485NULL-Werte 306

O

Oberklassen 156ändern 176Vererbung 160

ObjectPascal, Typisierung 101Objekt 31, 65

Aktion und Interaktion 412Assoziation 117Attribute 132Beziehungen 117Darstellung in UML 69Datenkapselung 67Definition 65Eigenschaften 68erzeugen 338Funktionalität 74gleichartig 84Gleichheit 254


652

Index

identisch 148Identität 81, 133, 147in relationaler Datenbank abbilden 307Klassenzugehörigkeit bestimmen 360Konstruktion 236Kontrakt 455kopieren 341, 442Laufzeit überdauern 299Lebenszyklus 509Methode 75Nachrichtenaustausch 419Operation 455prüft Kontrakt 464Rolle 83Sammlung 421Serialisierung 299sortieren 452Spezifikation von mehreren Klassen

erfüllen 261und Daten 76und Operation 74und Routine 423Verhalten modifizieren 344Zustand merken 442

Objekt erzeugenJavaScript 342Konstruktor 338Prototyp 342Singleton 377Verfahren 338

Objekt und Exemplar 85Objekt und Routine 423Objektbasierte Sichtbarkeit 108Objekte und Werte 81Objekteigenschaften 67Objekterstellung 338Objektfluss 415Objektidentität 151Objektinitialisierungs-Joinpoint 546Objektknoten 415Objektkopie

erstellen 444flach 341tief 341Zweck 442

Objektorientierte Analyse 19Objektorientierte Architektur 503Objektorientierte Programmiersprachen

Grundelemente 14

Objektorientierte SoftwareStruktur 65

Objektorientiertes SystemKomplexität reduzieren 45Vorteil 421Zustände verwalten 415

Objektorientiertes Systemdesign 504Objektorientierung

Basis 27Definition 13Grundelemente 27Prinzipien 24, 39Zweck 22

Objekt-relationale AbbildungsregelnDritte Normalform 327Vierte Normalform 332Zweite Normalform 325

Objekt-Relationale Mapper 301Observable-Observer � Entwurfsmuster,

Beobachtetes-BeobachterOffen für Erweiterung, geschlossen für

Änderung 50, 226Open-Closed-Principle 50Operation 74

auf Objekten ohne Klassenbeziehung aufrufen 202

auf primitiven Datentypen 114Aufruf 74, 545Definition 74Deklaration 76, 170implementieren 200Kontrakt 79mehreren Objekten zuordnen 211Semantik 455Syntax 455

Operationen mit gleicher SignaturC# 277Java 275

P

Parametrisierte Klassen 96C++ 192in UML 96Java 98

Parametrisierte statische Fabrik 355Partielle Klasse 376Persistenz 299


653

Index

PHP 574Dynamische Typisierung 578Klassen 574Klassen- und Objektvariablen 575Klassenkonstanten 576Klassenmethoden 576Konstruktor 577

Plugin 511Pointcut

Arten 547Definition 543

Polymorphe Methoden 229Konstruktion und Destruktion von

Objekten 236Polymorphie 32

Definition 193statisch 194, 229Vorteile 34, 198

Polymorphie im KonstruktorJava 237

Postconditions 90Präsentationsschicht 511Preconditions 89Primitive Datentypen 114Prinzip der Datenkapselung

Vorteile 32Prinzip der Ersetzbarkeit 162, 178, 276

Gründe für Verletzung 166Vererbung der Spezifikation 161

Prinzip einer einzigen Verantwortung 40, 73Entwurfsmuster Besucher 226Regeln 44Vorteil 42

Prinzip Trennung der Schnittstelle von der Implementierung 53

Prinzip Trennung von Anliegen 45Prinzip Umkehr der Abhängigkeiten 56Prinzip Wiederholungen vermeiden

Umsetzung 48Prinzipien 39Private Methoden, Ruby 108Private Vererbung 185

in Delegationsbeziehung umwandeln 186Profiling 553program to interfaces 53Programmabbruch 485

Programm direkt beenden 487Programm in definierter Weise beenden

486

Programmierfehler, Ursachen 489Programmiersprachen, strukturierte 28Programmverhalten ändern, mit

Annotations 566Protected 183protected internal 112Protokollierung der Abläufe 552Prototyp 342

Definition 342Entwurfsmuster 348

Prozedur, Definition 29Prozess 423Prüfung des Kontrakts

an Aufrufstelle 469bei Entwicklung 470beim Aufruf von Operationen 468gegenüber Implementierung 468mit Aspektorientierung 470

Python 95, 635Syntax 635Typisierung 100

Q

Qualifikatoren 125UML 126

Quelle 534Quelltext 534

ändern 50in verschiedene Quelltextmodule verteilen

377kopieren 49mit generierten Anteilen 535Redundanz 533Wiederholungen 47

Quelltextgenerierung 533Probleme 534

R

RAII 482Redundanz 47

bewusst 321vermeiden 244

Reference Counting 400Referenz 148Referenzielle Integrität 312Referenzzähler 400Reflection � Reflexion


654

Index

Reflexion 363Definition 538

Registratur 360, 364, 371Relation 303Relationale Datenbanken 300

Begriffsdefinition 303Partitionierung 309Struktur 301

Resource Acquisition is Initialisation 482Responsibility 40Richtung einer Assoziation 119Rollen

UML 119Routinen 423

als Objekte 436Definition 29

Ruby 374, 637private Methoden 108Sichtbarkeitsstufe Geschützt 110Syntax 638Typisierung 100

S

Sammlung 424Kopie 443über generischen Mechanismus kopieren

447Sammlung von Objekten, stellt Iterator

bereit 187Sammlungsbibliothek 187San Francisco Framework Classes 508Schablonenmethode 245, 507Schlüssel 304Schlüsselkandidaten 305Schnittstelle

Definition 75Implementierung 53implizit und explizit 275minimal vs. benutzerorientiert 549von Implementierung trennen 75von Klasse trennen 55

Schnittstelle einer Klasse, Definition 89Schnittstellen-Klassen 55, 168

Definition 168in C++ 174in Java und C# 174Umsetzung 173

Schwach typisierte Programmiersprachen 99

Separate Fabrik 373Separation of Concerns 45Sequenzdiagramm 413, 419Serialisierung von Objekten 299Service Locator 396Session Beans 151set 124Sichtbarkeit

auf aktuelles Objekt einschränken 107Vererbung 183

Sichtbarkeitskonzeptklassenbasierte 107objektbasiert 108

Sichtbarkeitskonzept, klassenbasiert 184Sichtbarkeitsstufe

Geschützt 183Öffentlich 106Privat 106Zweck 106

Sichtbarkeitsstufe XE 112Signal Send Action 415Single Responsibility Principle 40Single Table Inheritance 317Singleton

Einsatz 385oder globale Variable 385statische Initialisierung 382Umsetzung in Java 378

Singleton-Klasse 377Singleton-Methoden 116

Definition 116Smalltalk, Typisierung 100Smart Pointer 401soft references 400Software

Anforderungen 23Design verbessern 64Testbarkeit 62Umsetzung der Ziele 24

Softwarearchitektur 503Sortierkriterien 453Späte Bindung 194

realisieren 229Speicherbereich 397Speicherersparnis 139Sperre mit zweifacher Prüfung 381Spezifikation einer Klasse 91


655

Index

Spolsky, Joel 228Stack 397Standardkonstruktor 340Stateful Session Beans 151, 153Stateless Session Beans 151, 152Statisch typisiert 99Statisch typisierte Programmiersprachen

rein spezifizierende Klassen 169Statische Fabrik 352

parametrisiert 355Umsetzung 354

Statische Klassifizierung 289Statische Polymorphie 194, 229Statischer Speicher 397Statisches Crosscutting 548

Definition 541Statisches Typsystem 93Strategieklassen 296Struktur

Darstellung 31von objektorientierter Software 65von Programmen und Daten 28

Struktur des Programms, bei Laufzeit lesen 537

Strukturierte Programmierung 28Mechanismen 28

Subclass � UnterklasseSwing 566Synchrone Nachricht 419

T

Tabelle für virtuelle Methoden 421Template Method 247Test 62

automatisiert 62Vorteile 63

Testprogramm 62throws-Klausel erweitern 494Tiefe Kopie 449Timingdiagramm 413Top-down-Entwurf 56To-Space 406Transaktion 553

über dynamische Pointcuts 554Trennung der Anliegen 45, 527Trennung der Schnittstelle von der

Implementierung 53Trennung, Daten und Code 71

try-catch-Block 475Tupel 303Typ eines Objekts

zum Typ einer Unterklasse konvertieren 180

Typbestimmung zur Laufzeit 181Typisierte Sprachen

redundanter Code 96Typisierung

schwach 99stark 99Vor- und Nachteile 101

Typkonflikte 93Typsystem 94

Definition 92dynamisch 94, 95statisch 93Vererbung der Spezifikation 176

Typumwandlung in Java 99

U

Übergabe an abhängige Module � Dependency Injection

Übergreifende Anliegen � Crosscutting Concern

Überprüfte Exception � Checked Exception

Überprüfung während der Übersetzung mit Aspektorientierung 551

Überschreiben von Methoden 242Überschriebene Methoden 246Umkehr der Abhängigkeiten 56UML 412

Aggregation 130Assoziation 119Assoziationsklassen 127Beziehungsklasse 126Darstellung eines Objekts 69Diagrammtypen 412Einschränkungen von Beziehungen 124Kompostion 130Navigierbarkeit 120Qualifikatoren 126Rollen 119

UML-Diagramme, Verwendung 69Unified Modelling Language 19Unit-Test 62Unterklasse 157


656

Index

Unterklassen 156erben Funktionalität 239Exemplare 161Nachbedingungen ändern 164und Invariante 165Vorbedingung der Operationen 459Vorbedingungen verändern 164

Untermodul 40Unterprogramm aufrufen 30update anomaly 324

V

value object � WertobjektVariable 29Vererbung 34

Erweiterung von Modulen 505öffentliche Sichtbarkeit 184privat 185Sichtbarkeit 183, 184Varianten 241

Vererbung der Implementierung 35, 239Problem 250Programmiersprachen 240Verbot der Modifikation 244

Vererbung der Spezifikation 34Definition 157Typsystem 96, 176

Vererbung von Implementierungen 244Vererbungsbeziehungen in relationaler

Datenbank abbilden 315Vererbungsmöglichkeit, fehlend 271Vergleicher 452Vergleichsoperation der Basisklasse

umsetzen 257Verhalten von Programmen betrachten

413Verletzung eines Kontrakts

Programmabbruch? 485Vertrag � KontraktVielgestaltigkeit 193Vierte Normalform 330virtual 249Virtuelle Methoden

Fehler bei Anpassungen 232hinzufügen 234Reihenfolge 231überschreiben 232

Virtuelle Vererbung 287Virtuelle-Methoden-Tabelle 228, 229

Umsetzung 232Visitor 217VMT � Virtuelle-Methoden-TabelleVor- und Nachbedingung, Anforderungen

457Vorbedingung 89

prüfen 468Überprüfung 556

W

Wartbarkeit 24erhöhen 43verbessern 48

Weavring 541Werte 81, 133

als Objekte implementiert 134Identität 134objektorientierte Programmiersprachen

134Wertobjekt 134, 135

Änderung 137Definition 135Identität 151

Wiederholungautomatisch generiert 50Entstehung 49in Quelltexten 47

Wiederholung vermeiden 47

Z

Zählen von Referenzen 400Problem 403

Zusatzinformation in Programmstruktur einbinden 564

Zusicherung 456Zustand, Modellierung 417Zuständigkeitskette 367Zustandsautomaten 412Zustandsdiagramm 412, 415Zyklische Referenz 403

bei Kopien 449


Documents

Objektorientierte Programmierung - Amazon S3...7 Inhalt In diesem Kapitel stellen die Autoren sich und dieses Buch vor. Sie erklären, was Objektorientierung im Bereich der Softwareentwicklung