Grundlagen der Informatik I “Programmierung”

Nachkommenklassen obliegt, konkrete Anweisungsteile bereitzustellen. Eiffel verwendet hierfür das Schlüsselwort
deferred und sieht auch die gesamte Klasse als deferred, also aufgeschoben an. Selbstverständlich sind
aufgeschobene Klassen als solche nicht “ausführbar”.
Definition 3.8.9 (Aufgeschobene Klassen)
Eine Routine heißt aufgeschoben (deferred), wenn ihr Rumpf anstelle des Anweisungsteils das Schlüsselwort
deferred enthält.
Eine Klasse heißt aufgeschoben, wenn sie eine aufgeschobene Routine enthält oder eine aufgeschobene
Routine geerbt und nicht ausführbar redefiniert hat. Sie muß in ihrer Deklaration als deferred class
gekennzeichnet werden.
Aufgeschobene Klassen sind das Eiffel-Gegenstück zu der axiomatischen Spezifikation abstrakter Datentypen,
da sie wie diese nur die Dienstleistungen einer Klasse und deren Eigenschaften beschreiben, nicht aber die
Implementierung. Damit können sie benutzt werden, um abstrakte Schnittstellen innerhalb von ausführbaren
Programmen zur Verfügung zu stellen. Das bedeutet, daß bereits während der Entwicklungsphase eine Kundenklasse
der aufgeschobenen Klasse übersetzt und teilweise getestet werden kann, ohne daß eine konkrete
Realisierung der Lieferantenklasse bereits vorliegt. Vererbung erlaubt es dann, beliebige konkrete Realisierungen
und Verfeinerungen der aufgeschobenen Klasse anzugeben.
Diese Technik unterstützt einen Entwurf großer Softwaresysteme auf einer hohen Abstraktionsebene. Es ist
möglich, innerhalb ein und derselben Sprache zunächst eine Systemarchitektur zu entwerfen, jedes Modul
abstrakt zu beschreiben und Implementierungsdetails in späteren Verfeinerungen auszuführen 29 . Da auch
unimplementierte Routinen präzise durch Vor- und Nachbedingungen charakterisiert werden können, verschwindet
ein Großteil der konzeptionellen Lücke zwischen Entwurf und Implementierung.
Ein weiterer Vorteil aufgeschobener Klassen ist die Möglichkeit einer gleitenden Realisierung von Softwaresystemen
(“partielle Implementierung”). In aufgeschobenen Klassen können auch ausführbare Routinen
vorkommen, die dann für alle Erben zur Verfügung stehen. Auf diese Weise erhält man eine Klassifikation der
Implementierungen von der abstrakten Form in die verschiedenen Formen ihrer konkreten Realisierung.
Darüber hinaus bieten deferred classes einen Ersatz für Prozedurparameter in Routinen, die in Eiffel – im
Gegensatz zu den meisten höheren Programmiersprachen – nicht erlaubt sind. Solche Parameter aber sind
zum Beispiel sinnvoll, wenn man in einer mathematischen Programmpaket Integration und ähnliche Verfahren
anbieten will, natürlich ohne dabei bereits die Funktion festzulegen, deren Integral berechnet werden soll. In
Eiffel läßt sich das so simulieren, daß man eine deferred Routine anstelle des Prozedurparameters definiert, die
dann in den Erben dieser Klasse durch die jeweilig gewünschte aktuelle Routine ersetzt wird.
Eines der wichtigsten Anwendungsgebiete aber ist die polymorphe Anwendung von gleichartigen (und gleichnamigen)
Routinen aus verschiedenen Anwendungsbereichen. So kann man zum Beispiel für graphische Objekte
wie Punkte, Vektoren, Segmente, Rechtecke, Polygone usw. jeweils unabhängig Routinen zum verschieben,
drehen, spiegeln usw. deklarieren und implementieren. Jede dieser Routinen muß in jeder Klasse völlig
unabhängig realisiert werden, führt aber – intuitiv betrachtet – jeweils dasselbe aus. Was liegt also näher, als
diese als Routinen einer Klasse GRAPHISCHE OBJEKTE anzusehen, die einen einheitlichen Namen haben und in
den jeweiligen Spezialisierungen ihre besondere Ausprägung finden? Diese gemeinsame Oberklasse muß eine
aufgeschobene Klasse sein, denn es gibt keine feste Anweisungsfolge, die sagt, wie man graphische Objekte
generell verschiebt. Man kann nur in den Vor- und Nachbedingungen festlegen, was die Effekte sein sollen.
Aufgeschobene Klassen bilden also den Vereinigungstyp aller Erbenklassen. Dies erlaubt es den Kunden einer
deferred Klasse wie GRAPHISCHE OBJEKTE, abstrakte Programme zu schreiben, die für jeden konkreten Spezialfall
– also Punkte, Vektoren, Segmente, Rechtecke, Polygone usw. – funktionieren, da die Erbenklassen
eine Implementierung bereitstellen.
29 Normalerweise muß man hierfür mindestens zwei formale Sprachen verwenden – eine Spezifikations- und eine Implementierungssprache.
Dies bringt jedoch eine Reihe von Problemen mit sich, wenn man von der einen auf die andere Sprache übergehen
will und dabei sicherstellen möchte, daß die Lösung in der Implementierungssprache der abstrakten Beschreibung in der Spezifikationssprache
entspricht.