Grundlagen der Informatik I “Programmierung”

4.1.2 Grundideen des objektorientierten Entwurfs
Bei einem reinen objektorientierten Vorgehen, wie es durch die Programmiersprache Eiffel unterstützt wird,
ist zu beachten, daß Klassen der einzige Strukturierungsmechanismus für Systeme sind. Sie sind unabhängige
Einheiten, obwohl sie durch Benutzung und Vererbung miteinander verbunden sein können. Aus Sicht der
Programmiersprache liegen alle Klassen auf der gleichen Ebene und dürfen – genau wie Routinen – nicht
geschachtelt werden. Diese Eigenständigkeit von Softwareteilen ist wesentlich für Wiederverwendbarkeit und
einer der wichtigsten Unterschiede zu den gängigen blockstrukturierten Sprachen.
Eine Klasse kann als ein Lager von Dienstleistungen (exportierten features) angesehen werden, die auf den
Exemplaren eines Datentyps verfügbar sind. Diese Dienste werden allen Kunden, die sie überhaupt benutzen
dürfen, gleichermaßen zur Verfügung gestellt:
• Es gibt keine Operationen mit höherer oder niedriger Bedeutung, insbesondere keine Hauptfunktion –
selbst dann, wenn bestimmte Dienste häufiger in Anspruch genommen werden als andere.
• Es gibt keine Vorschriften über die Reihenfolge, in der Dienstleistungen aufgerufen werden dürfen.
Die Reihenfolge mag zwar bei der eigentlichen Ausführung eines Systems von großer Bedeutung sein. Es
wäre jedoch ein Fehler, diese Reihenfolge schon bei der Deklaration der entsprechenden Dienstleistungen
einzufrieren. Die Festlegung einer solchen Reihenfolge ist ausschließlich Sache der Kunden.
Natürlich gibt es Gründe festzulegen, daß eine Operation wie das Herausnehmen von Elementen aus
einer Liste nur ausgeführt werden kann, wenn zuvor eine andere Operation – das Einfügen von mindestens
einem Element – stattgefunden hat. Dies ist aber eine Vorbedingung für die Ausführbarkeit der
Operation und sollte auch als solche formuliert werden. Es liegt dann in der Verantwortung des Kunden,
was er damit macht.
Eine Folge dieses Prinzips ist, daß es keine Gründe gibt, die Anzahl der features einer Klasse zu beschränken.
Hat eine Operation einen logischen Bezug zu dieser Klasse, so kann man sie hinzufügen, auch wenn unklar ist,
ob sie von vielen Kunden benötigt wird. 2 Das Problem, daß eine Klasse eine unüberschaubare Größe bekommen
kann, ist verhältnismäßig gering, da eine zu große Anzahl von Dienstleistungen (ein zu breites Spektrum im
Lager) selten stört, da man sich bei der Betrachtung von Informationen auf die features beschränken kann,
die man tatsächlich braucht. Einzig die Suche nach noch unbekannten, aber eventuell brauchbaren features
wird durch eine zu große Anzahl von features etwas erschwert.
Anders ist es beim Code einer einzelnen Routine. Dieser sollte kurz und überschaubar bleiben, was aber
bei der objektorientierten Sichtweise von Routinen als wohldefinierte Einzeldienstleistung selten ein Problem
werden wird.
Aufgrund der Hervorhebung des Wiederverwendbarkeitsaspektes eignen Klassen sich besonders für einen
Entwurfsstil, der sich stark auf bereits existierende Module stützt (“Bottom-up Entwurf”). 3 Die Stärke der
objektorientierten Programmierung liegt in der Aktivierung fertiger Programmteile. Deshalb lohnt es, sich
mit vordefinierten Klassen der Eiffel-Basisbibliothek und gegebenenfalls auch anderer Bibliotheken vertraut
zu machen und neu zu entwickelnden Klassen möglichst allgemein zu gestalten, damit sie später auch in
anderen Lösungen verwendet werden können.
2Das Problem, daß hierdurch beim Zusammensetzen eines Systems viel unbenutzter Code erzeugt wird, kann durch den
Eiffel-Optimierer gelöst werden.
3Natürlich kann man den Entwurf nicht losgelöst von der eigentlichen Problemstellung durchführen. Ein reiner “Top-Down
Entwurf”, wie er früher favorisiert wurde, konzentriert sich aber zu sehr auf das Problem und man muß wichtige Entscheidungen
über die Softwarestruktur in einer Phase fällen, in der das Bild noch sehr vage ist und Wesentliches von Unwesentlichem noch
nicht getrennt werden kann. Dadurch – und vor allem durch Vernachlässigung der Tatsache, daß es bereits Lösungen für ähnlich
gelagerte Problemstellungen geben kann – wird der Entwickler von der Komplexität des Problems geradezu erschlagen und
Fehlentscheidungen werden gravierende Folgen auf das entstehende Produkt haben. Top-Down Entwicklung von Programmen
bietet sich erst während der Implementierungsphase an, nachdem die Struktur des Gesamtsystems bereits so weit untergliedert
ist, daß jedes Teilproblem überschaubar ist.