Grundlagen der Informatik I “Programmierung”

Das Problem ist nun, daß beide Elternklassen, STUDENT und UNI-ANGESTELLTE das feature fachbereich benutzen.
Bei Aufruf dieses features ist also nicht klar, welches der beiden gemeint sein soll. Solche Konflikte
müssen in einer Programmiersprache verboten werden, da die Wahl des geerbten features ja nicht zufällig
getroffen werden kann und es unwahrscheinlich ist, daß in beiden Fällen dasselbe gemeint ist. So bezeichnet
zum Beispiel das feature fachbereich bei Studenten das Hauptfach, das sie studieren, und bei Universitätsangestellten
den Fachbereich, an dem sie arbeiten. Daher gilt
In Eiffel sind Mehrfachvererbungen mit Namenskonflikten verboten.
Die Klasse HILFSKRAFT, so wie sie oben beschrieben ist, würde also vom Compiler abgelehnt werden. 32
Wie kann man sich nun behelfen? Es wäre wenig sinnvoll zu verlangen, daß die Namen aller im System deklarierten
Routinen verschieden sein müssen, da dies eine praktische Weiterentwicklung einer Eiffel-Bibliothek
erheblich erschweren würde. Man kann die Eltern nicht dafür verantwortlich machen, daß in einer Erbenklasse
Namenskonflikte auftreten. Es ist eher das Problem der Erben, welche diese Kollision durch die Wahl
der Elternklassen erzeugt haben. Deshalb muß das Problem auch in der Erbenklasse gelöst werden.
Die einfachste Möglichkeit hierfür ist eine Umbenennung von features, d.h. ein Mechanismus, der es ermöglicht,
features unter anderen Namen anzusprechen 33 . Hierzu gibt man in der Erbklausel eine rename-Unterklausel
an, welche beschreibt, unter welchen Namen geerbte features weiterbenutzt werden sollen. In unserem Beispiel
würde man also das feature fachbereich der Klasse STUDENT in studienfachbereich umbenennen. Die Eiffel
Syntax für Umbenennungen lautet
rename
feature1 as new feature1,
.
featuren as new featuren
Man achte darauf, daß mehrere Umbenenungen durch Komma getrennt sind und nicht durch Semikolon.
Umbenennung hat, wie das Beispiel in Abbildung 3.39 zeigt, auch einen Einfluß auf die features, die in den
export- und redefine-Klauseln genannt werden. Allgemein gilt, daß nach einer Umbenennung nur noch der
neue Name bekannt ist. Daher muß die rename-Unterklausel vor allen anderen Unterklauseln einer Erbklausel
genannt werden.
Entwurfsprinzip 3.8.11 (Regel der Feature-Umbenennung)
Features, die in einer rename-Unterklausel umbenannt wurden, können in export- und redefine-Klauseln
nur unter ihrem neuen Namen angesprochen werden.
Neben der Beseitigung von Namenskonflikten gibt es auch weitere sinnvolle Anwendungen für Umbenennungen.
So ist oft der Name, unter denen eine Klasse ein feature erbt, für den speziellen Verwendungszweck nicht
aussagekräftig genug. Die Routine gehalt hat sich bisher zum Beispiel nur auf das Bruttogehalt bezogen, für
das Arbeitgeber und Finanzamt sich interessieren. Für die Familie zählt aber, was nach Steuern und Sozialabgaben
übrigbleibt – das Nettogehalt. In Erbenklassen von ARBEITNEHMER kann es also durchaus ratsam
sein, das feature gehalt in bruttogehalt umzubenennen.
Umbenennung ist ein syntaktischer Mechanismus, der sich auf die Namensgebung für ein feature innerhalb
einer Klasse und ihrer Erben auswirkt. Wichtig ist jedoch, daß Umbenennung keinen Effekt auf die Vorfahrenklassen
hat. Das feature ist für Größen, deren Typ eine Ahnenklasse der umbenennenden Klasse ist, nach wie
32 Diese Regel gilt nicht, wenn die Klassen, in denen die kollidierenden Namen deklariert wurden, deferred sind. In diesem
Falle besteht ja keine Schwierigkeit festzustellen, welche Implementierung bei einem Aufruf des features gefragt ist – es gibt ja
keine. Die Regelung für diesen Fall besagt, daß beide aufgeschobenen Routinen zu einer neuen aufgeschobenen Routine vereinigt
werden, die ggf. auch dann eine effektive Version erhalten kann. Mehr zu diesem join Mechanismus und den Möglichkeiten,
diesen durch rename und undefine auch auf effektive features auszudehnen, findet man in [Meyer, 1992, Kapitel 10.17/18].
33 Damit ist Umbenennung komplementär zur Redefinition, die mit demselben Namen unterschiedliche Implementierungen
eines features anspricht – abhängig vom Typ des Objektes. Redefinition ist also ein semantischer Mechanismus, Umbenennung
ist ein rein syntaktischerMechanismus, der gewährleistet, daß dieselbe Implementierung eines features – abhängig vom Typ des
Objektes – unter unterschiedlichen Namen angesprochen werden kann.