Grundlagen der Informatik I “Programmierung”

Ist also p ein Personenobjekt und a ein Arbeitnehmerobjekt, so ist der Aufruf a.name, a.vornamen
genauso erlaubt wie p.name, p.vornamen. Darüber hinaus kann man allerdings auch a.adresse
und a.gehalt aufrufen, nicht jedoch p.adresse oder p.gehalt
Dies gilt natürlich nur dann, wenn die geerbtes features nicht durch export-Klauseln von der
Weiterverwendung ausgeschlossen werden.
Diese Eigenschaft läßt sich als eine erste wichtige Regel des Typsystems von Eiffel beschreiben.
Entwurfsprinzip 3.8.2 (Regel der Featureanwendung)
Ist eine Größe entity vom Klassentyp K, so ist die Anwendung entity.f eines feature f nur dann
zulässig, wenn f in einem Vorfahren von K definiert wurde.
Man beachte, daß diese Regel “nur dann” und nicht etwa “genau dann” besagt. Die Voraussetzung, daß ein
feature in einem Vorfahren von K (d.h. eventuell auch in K selbst) definiert wurde, ist notwendig für eine
Anwendung, reicht aber nicht immer aus – zum Beispiel, weil das feature durch die Klasse K nicht oder nur
selektiv exportiert wurde.
Die Interpretation des selektiven Exports von features wird allerdings durch die Vererbung etwas aufgeweicht.
Da Erben alle Rechte ihrer Vorfahren besitzten, haben sie natürlich auch alle Zugriffsrechte. Das bedeutet,
daß ein selektiv an eine Klasse exportiertes feature auch innerhalb aller Erbenklassen zur Verfügung steht –
selbst, wenn diese nicht explizit in der export- bzw. feature-Klausel genannt sind.
Entwurfsprinzip 3.8.3 (Regel des selektiven Exports)
Ein an eine Klasse K selektiv exportiertes feature f darf in allen Nachkommen von K benutzt werden.
In den folgenden Abschnitten werden wir weitere Regeln des Typsystems von Eiffel vorstellen. All diese Regeln
sind statischer Natur, d.h. sie können ausschließlich auf der Basis des Programmtextes überprüft werden 23 .
Der Compiler wird Klassen abweisen, die eine dieser Regeln verletzen. Auf diese Art wird sichergestellt, daß
es während der Laufzeit eines Systems nicht mehr zu Typfehlern kommen kann.
3.8.3 Redefinition
So wie es Gründe dafür gibt, geerbte features selektiv an verschiedene Klassen zu exportieren, gibt es auch
Gründe, ihre Implementierung zu verändern. So wird zum Beispiel bei Universitätsangestellten das Gehalt
nicht alleine aufgrund der Gehaltsklasse bestimmt, sondern hängt zusätzlich vom tatsächlichen Alter der
Angestellten ab ab. Das bedeutet, daß die Funktion gehalt bei Universitätsangestellten nach einem anderen
Verfahren berechnet werden sollte als im Allgemeinfall. Um dies zu ermöglichen, erlaubt Eiffel, geerbte features
neu zu definieren. Hierzu wird in einer redefine Klausel angegeben, welche features verändert werden. Natürlich
muß jetzt jedes dieser features erneut als feature der Klasse deklariert und implementiert werden.
Abbildung 3.32 enthält eine Deklaration der Klasse aller Universitätsangestellten, in der das feature gehalt
neudefiniert wurde. Ohne die redefine-Klausel wäre die erneute Deklaration von gehalt als Merkmal von
UNI-ANGESTELLTE ein Fehler, da gehalt bereits aus der Klasse ARBEITNEHMER übernommen wird.
Die redefine-Klausel teilt mit, welche features einer Elternklasse in einer Erbenklasse neudefiniert werden 24 .
Hierdurch wird gewährleistet, daß derselbe Name sich auf verschiedene aktuelle features beziehen kann.
Abhängig vom Typ des Objektes, auf das es angewandt wird, erhält man eine andere Implementierung.
23 Für fast alle Regeln gibt es im Referenzbuch [Meyer, 1992] verfeinerte Formen. Diese behandeln jedoch auch alle Spezialfälle,
die sich aus Kombinationen diverser Möglichkeiten ergeben und sind zur Erklärung des eigentlichen Prinzip ungeeignet.
24 Der Compiler benötigt die redefine-Klausel eigentlich nicht, weil jede erneute Deklaration eines ererbten features ja nur eine
Redefinition sein kann, sofern kein Fehler des Programmierers vorliegt. Da aber irrtümliche Redefinitionen bei umfangreichen
Ahnenklassen nicht unbedingt ausgeschlossen werden können, muß Redefinition ausdrücklich als solche gekennzeichnet werden.
Dies erhöht die Sicherheit und Lesbarkeit der Programme.
Es sei an dieser Stelle auch erwähnt, daß ein feature durch das Schlüsselwort frozen gegen Redefinition sperren kann, wenn
man darauf Wert legt, allen Benutzen eine eine unveränderliche Implementierung bereitzustellen.