Grundlagen der Informatik I “Programmierung”

Prinzipiell wäre es sogar möglich, daß eine Klasse K dieselbe Elternklasse mehrfach in ihrer Erbklausel
auflistet, um ggf. ein feature unter mehreren Namen anzubieten. Da man diese Konstellation nicht prinzipiell
ausschließen kann, muß sie sehr sauber geregelt werden.
Man könnte nun verlangen, daß alle wiederholt auftretenden features durch Umbenennung getrennt werden
müssen, aber das Beispiel der Hilfskräfte zeigt, daß dies nicht gerade sinnvoll ist. Die doppelt von PERSON
geerbten features sind ja in Wirklichkeit absolut identisch, da sie weder umbenannt noch redefiniert wurden.
Deshalb möchte man sie ohne Komplikationen wieder als einfach vorkommende features benutzen können.
Entwurfsprinzip 3.8.12 (Regel des wiederholten Erbens)
Bei wiederholtem Erben wird jedes feature des gemeinsamen Vorfahren als gemeinsam genutzt (shared)
angesehen, wenn es auf dem gesamten Vererbungspfad nicht umbenannt wurde. Features, die auf mindestens
einem Wege umbenannt wurden, werden als vervielfältigt (replicated) angesehen.
Die Regel besagt also, daß alleine der Name eines wiederholt ererbten features festlegt, wie oft es in einem
Erben vorkommen muß. Normalerweise erzeugt ein wiederholt geerbtes feature keine Kollision, sondern wird
wieder zu einem einzelnen feature vereinigt.
Jede Umbenennung eines features auf dem Vererbungpfad von der erstmalig deklarierenden Ahnenklasse zum
Erben erzeugt jedoch eine weitere Kopie dieses Merkmals. Hierfür gibt es durchaus eine Reihe von Anwendungen.
So könnten zum Beispiel STUDENT und UNI-ANGESTELLTE von der Klasse PERSON ein weiteres
feature adresse geerbt haben – im ersten Fall als Wohnadresse, im zweiten als Adresse des Arbeitsplatzes.
In HILFSKRAFT kommen nun beide Versionen vor, so daß dieses feature beim Erben umbenannt werden sollte
und somit vervielfältigt wird. Die Umbenennung kann in der Klasse HILFSKRAFT stattfinden, aber sinnvoller
wäre es, dies bereits vorher zu tun.
Die Regel des wiederholten Erbens gilt gleichermaßen für Routinen und Attribute. Nicht erlaubt ist daher, daß
eine gemeinsam genutzte Routine (in der definierenden Klasse) Verweise auf Attribute oder Routinen enthält,
die auf dem Vererbungspfad umbenannt wurden. Wegen der Vervielfältigung wären diese in der Erbenklasse
nicht mehr eindeutig zu identifizieren. Derartige Routinen müssen auf dem Vererbungsweg ebenfalls an
passender Stelle umbenannt werden. (Tut man dies zu spät, so muß man sogar umbenennen und redefinieren!)
So, wie sie bisher formuliert wurde, hinterläßt die Regel des wiederholten Erbens noch ungeklärte Probleme bei
features, die an formale generische Parameter gebunden sind. In der folgenden Situation, die in komplexerer
Form auch bei indirektem wiederholten Erben auftreten kann, wird ein feature f auf dem Vererbungsweg
nicht umbenannt, erhält aber beim Erben verschiedene Typen.
class GENERISCH[X] feature
f:X; ....
end -- GENERISCH
class ERBE inherit
GENERISCH[INTEGER]; GENERISCH[PERSON]
.
end -- ERBE
Bei einer gemeinsamen Nutzung von f wäre unklar, ob f vom Typ INTEGER oder vom Typ PERSON ist. Ähnliche
Mehrdeutigkeiten träten auf, wenn f als eine Routine mit einem formalen Argument vom Typ X deklariert
worden wäre. Diese Mehrdeutigkeit wird durch die folgende Regel eliminiert.
Entwurfsprinzip 3.8.13 (Regel der Generizität bei wiederholtem Erben)
Der Typ eines beim wiederholten Erben gemeinsam genutzten features darf in der Elternklasse kein
generischer Parameter sein. Ebenso darf eine gemeinsam genutzte Routine in der Elternklasse keine
formalen Argumente enthalten, deren Typ ein generischer Parameter ist.