Grundlagen der Informatik I “Programmierung”

Eine Konsequenz dieser Regel ist, daß die oben beschriebene Situation als Namenskonflikt gilt, der durch
Umbenennung beim Erben aufgelöst werden muß. Dies führt dann zur Vervielfältigung des features gemäß
der Regel des wiederholten Erbens.
Unter Berücksichtigung des wiederholten Erbens können wir jetzt das in Abschnitt 3.8.8 angesprochene Verbot
von Namenskonflikten präzisieren.
Entwurfsprinzip 3.8.14 (Umbenennungsregel)
In einer Klasse K tritt ein Namenskonflikt auf, wenn zwei Eltern E1 und E2 von K ein feature mit
demselben Namen f enthalten.
Ein Namenskonflikt ist erlaubt, wenn f in einem gemeinsamen Vorfahren V von E1 und E2 erstmalig
definiert wurde, auf keinem Vererbungspfad von V nach E1 und nach E2 umbenannt wurde und in seiner
Typdeklaration an keine generischen Parameter von V gebunden ist.
Nicht erlaubte Namenskonflikte müssen durch Umbenennung aufgelöst werden.
Weitere Komplikationen bei wiederholtem Erben können durch Redefinition entstehen. Es kann sein, daß
features auf verschiedenen Wegen zum gleichen Erben auch verschiedene Bedeutungen erlangt haben können.
In diesem Fall liegt zwar keine Namenskollision im eigentlichen Sinne vor, aber die gemeinsame Nutzung
würde dennoch zu Problemen führen, da dieses feature nun in mehreren Versionen geerbt wird.
Bei einem Aufruf des features durch eine Größe, deren Typ die Ahnenklasse ist, kann nun keine eindeutige
dynamische Bindung zwischen dem Originalnamen des Aufrufs und der tatsächlich zu verwendenen Implementierung
mehr stattfinden. Auch Umbenennung löst dieses Problem nicht, da die Ahnenklasse die Namen
nicht kennen kann, die eine Erbenklasse neu vergibt (die würde ja einen Eingriff in die Ahnenklasse beim
Programmieren der Erben verlangen).
In diesem Fall muß daher die Erbenklasse auswählen, welche Version des features dynamisch an frühere Versionen
gebunden wird und welche nicht. Dies geschieht in Eiffel durch eine select-Unterklausel der entsprechenden
Erbklausel. Eine solche Unterklausel beginnt mit dem Schlüsselwort select und listet danach die endgültigen
Namen derjenigen features, welche dynamisch an frühere Versionen gebunden werden sollen. Nicht selektierte
Versionen sind nur von den Nachfolgerklassen, nicht aber von den Ahnen her erreichbar.
[Meyer, 1992, Kapitel 11] liefert eine detaillierte Betrachtung des wiederholten Erbens und die genaue Festlegung
weiterer Sonderfälle. Wir wollen im Rahmen dieser Veranstaltung nicht weiter darauf eingehen. Wiederholtes
Erben wird in der Praxis nicht sehr häufig gebraucht. Eine Systemkonfiguration muß schon verhältnismäßig
komplex sein, bevor diese Einrichtung wirklich benötigt wird.
In unkomplizierten Fällen ensteht wiederholtes Erben eher durch einen Anfängerfehler, bei dem die Transitivität
der Vererbung ignoriert wird. Oft wird zum Beispiel die Klasse STD FILES explizit mit in die Erbklausel
aufgenommen, um sicherzustellen, daß Ein- und Ausgabekommandos unqualifiziert genutzt werden können.
Dabei wird vergessen, daß diese Klasse bereits Vorfahre anderer Klassen ist, die man ebenfalls beerbt. Die
Aufzählung von STD FILES wird also überflüssig. Aufgrund der Regel des Wiederholten Erbens ist dies aber
nur ein uneleganter Programmierstil, der nicht zu einem Fehler führt.
3.8.10 Vererbung und Zusicherungen
Am Ende des Abschnitts 3.8.4 hatten wir bereits darauf hingewiesen, daß Redefinition prinzipiell die Möglichkeit
einer kompletten Veränderung der Semantik ererbter features ermöglicht. Dies birgt natürlich das Risiko
eines Mißbrauchs in sich, der gerade durch das dynamische Binden sehr gefährlich werden könnte. Dies kann
nur durch ein enges Zusammenspiel von Zusicherungen und Vererbung verhindert werden. Die Grundregel
hierfür haben wir bereits öfter angedeutet:
Was die Ahnen versprechen, müssen die Erben erfüllen!