Grundlagen der Informatik I “Programmierung”

Um die hier genannten Vorteile ausnutzen zu können, ist es wichtig, sich die Denkweise des objektorientierten
Entwurfs anzueignen und das zentralistische Denken, in dem das “Hauptprogramm” eine so wichtige Rolle
spielt, beiseite zu legen, wenn man es sich schon angewöhnt hat. Bei größeren Softwaresystemen ist eine
dezentrale Architektur mit überschaubaren, unabhängigen und gleichberechtigten Einheiten unverzichtbar.
4.1.3 Aufspüren der Klassen
Die Frage, die sich hierbei natürlich direkt ergibt, ist “wie finde ich die Klassen, die ich brauche?”. Hierauf
gibt es bisher keine allgemeingültige Antwort (und wahrscheinlich wird es auch nie eine solche geben), aber
zumindest ein paar allgemeine Einsichten.
Da Lösungskritik leichter ist als Lösungen zu schaffen, sollte man zunächst lernen, vorhandene Entwürfe zu
analysieren und ihre Stärken und Schwächen zu beurteilen, um daraus Erfahrungen für eigene Entwürfe zu
gewinnen. Hierzu werden besonders die Kriterien aus Abschnitt 3.10 hilfreich sein. Es lohnt sich auch, in
Teams zunächst unabhängig mehrere Lösungsansätze aufzustellen und dann zu beurteilen. Zum einen findet
man hierdurch unter Umständen eine Lösung, die besser ist als jede einzelne, und zum zweiten weist die Kritik
oft auf Denkfehler hin, die man beim nächsten Entwurf vermeiden kann. Aus Fehlern lernt man eine ganze
Menge, aber nur wenn man zuläßt, daß diese auch aufgedeckt werden. Wer aber (sachliche) Kritik vermeidet,
der wird auch selten etwas lernen.
Für das Aufspüren von Klassen, die benötigt werden, um geforderte Leistungen mit geringerem Aufwand zu
beschreiben, bietet es sich an, zunächst einmal die Eiffel-Bibliotheken nach Lösungen für ähnliche Problemstellungen
zu durchforsten. Für wichtige Datenstrukturen wie Listen, Bäume, Felder, Stacks, Queues, Dateien,
Strings, Hash-Tabellen, Bäume, usw. gibt es für nahezu alle Routineaufgaben (wie Einfügen, Löschen, sortieren
etc.) längst eine vordefinierte Lösung, auf die man zurückgreifen kann. Da mindestens die Hälfte aller
Probleme aus derartigen Routineaufgaben besteht, erspart dieser naive, aber doch sehr wirksame Weg eine
Menge Arbeit und reduziert das Risiko von Fehlern.
Ein weiterer wichtiger Hinweis ist, daß viele Klassen keine andere Aufgabe haben werden, als das Verhalten
externer Objekte zu modellieren. Ihre features und Eigenschaften ergeben sich also nahezu direkt aus der
Grobspezifikation.
Ob ein Begriff aus der realen Welt als Klasse realisiert werden soll, hängt vor allem davon ab, wie damit
umgegangen werden soll. Interessiert man sich zum Beispiel in einem Bibliothekssystem nur für Namen und
Vornamen des Autors eines Buches als Ordnungskriterium, führt aber keine Operationen auf Autoren durch,
so sollten Autoren nicht als eigene Klasse deklariert werden. Stattdessen sollte die Klasse BUCH zwei Komponenten
für Namen und Vornamen beinhalten. Anders sieht dies aus, wenn man z.B. in einem angeschlossenen
Informationssystem über Buchautoren immer die aktuelle Adresse mitverwalten und ggf. ändern möchte. Hier
lohnt es sich schon, Autoren in einer separaten Klasse zusammenzufassen.
Im allgemeinen kann man sagen, daß oft zu viele unnötige Klassen gebildet werden. Ein Begriff sollte genau
dann zur Klasse erhoben werden, wenn er eine Menge von Objekten beschreibt, die interessante Operationen
mit axiomatisch charakterisierbaren Eigenschaften besitzen.
4.1.4 Schnittstellentechniken
Ebenso wichtig wie die Strukturierung eines Systems in Klassen ist der Entwurf guter Schnittstellen, also die
Fixierung derjenigen features, die nach außen hin angeboten werden. Die Qualität und Verständlichkeit dieser
Schnittstellen bestimmt, in welchem Maße eine Klasse auch tatsächlich benutzt werden wird.
Eine der wesentlichen Richtlinien ist hierbei eine strikte Trennung von Prozeduren und Funktionen. Die Programmiersprache
Eiffel läßt prinzipiell zu, daß Funktionen nicht nur Werte berechnen, sondern gleichzeitig
auch “Seiteneffekte” haben, d.h. während ihrer Abarbeitung auch das aktuelle Exemplar verändern. Es ist