Die Möglichkeiten der Vererbung sind sehr ausdrucksstark, haben viele Vorteile, bergen aber auch Risiken. Hierbei muss man mindestens drei verschieden Entwicklerrollen beachten:

• Implementierer der Oberklasse
  • entwirft ein semantisches Konzept für eine Klassenhierarchie
  • implementiert allgemeingültige Methoden und Attribute
  • gibt Rahmenwerk durch Zugriffsmethoden, Zugriffskontrolle, explizite Möglichkeit zum Vererben und Überschreiben vor
• Implementierer der Unterklasse
  • nutzt Infrastruktur
  • muss sich an Syntax und Zugriffskontrollen halten
  • macht Annahmen über Semantik der Oberklasse
  • verfeinert und verändert Funktionalität
• Benutzer der Klassenhierarchie
  • macht Annahmen zur gesamten Klassenhierarchie
    • nutzt Syntax
    • erschliesst Semantik aus Klassendeklaration, Dokumentation und experimenteller Benutzung
  • muss sich an Syntax und Zugriffskontrollen aller Klassen halten

Semantische Integrität von Unterklassen

Unterklassen müssen Spezialisierungen der Oberklassen sein. Sie müssen sich in allen semantischen Belangen wie die Oberklasse verhalten.

Vorteile

• Existierende Methoden können
  • benutzt werden
  • komplett überschrieben werden
  • überschrieben und die Methode der Oberklasse rekursiv genutzt werden
• Existierende Funktionalität von Oberklassen können sehr einfach genutzt werden

Risiken

• Überschriebene Methoden haben eine Semantik die nicht vom Entwickler der Oberklasse oder dem Benutzer der Unterklasse verstanden werden
  • Das heißt, dass die Methoden eventuell unter falschen Annahmen benutzt werden und entsprechenden Schaden anrichten
• Unterklassen erben unnötige Infrastruktur (Methoden) die den Pflegeaufwand in die Höhe treiben oder externe Benutzer verwirren

Ändern von Oberklassen

Änderungen an Oberklassen sind heikel, da sie die Implementierungen der Unterklassen invalidieren können:

• Entfernen von öffentlichen Methoden oder Attributen wird die Unterklassen invalidieren. Überschriebene Methoden werden plötzlich zu regulären. Der Polymorphismus gilt nicht für identische Methoden zweier Unterklassen wenn die Methode nicht in der Oberklasse als abstrakte Methode implementiert ist
• Nicht abstrakte Methoden abstrakt machen invalidiert die Unterklassen. Alle Unterklassen müssen die abstrakte Methode implementieren
• Hinzufügen von Methoden oder Attributen birgt das Risiko, dass sie Aufgrund zufälliger Namensgleichheit in den Unterklassen zu überschriebenen Methoden führen

Wichtig: Die Modellierung einer Klassenhierarchie muss sehr sorgfältig geschehen. Das möglichst exakte Abbilden realer Hierarchien ist für eine langlebige und wartbare Implementierung sehr wichtig.

Alternativen zur Vererbung

Vererbung birgt auch Risiken da eine Klassenhierarchie relativ starr ist und individuelle Änderungen weitreichende Auswirkungen haben können.

Vererbung sollte immer dann eingesetzt werden wenn man eine "ist-ein" Beziehung modellieren möchte.

In vielen Fällen liegt aber auch eine "hat-ein" Beziehung vor, eine Assoziation. Hier sollte man erwägen zwei Objekte zu erzeugen und sie über eine Referenz zu verwalten.

Im vorhergehen Beispiel ist es eine Überlegung wert, das Budget der Klasse Manager als Referenz von der Klasse Employee auf eine Klasse Budget zu implementieren. Hierbei sind die folgenden Dinge abzuwägen:

• Nachteile der Assoziation
  • Höherer initialer Implementierungsaufwand zur Datenkaspelung
    • Referenz + Zugriffsmethoden + Belegung im Konstruktor mit Objekterzeugung des Budgets
  • Jeder zusätzliche Aspekt der Klasse muss als Assoziation implementiert werden
  • Zusätzliche Aspekte der Klasse sind nicht in der Klassenhierarchie sichtbar
  • Zusätzlicher Speicherverbrauch durch zusätzliche Objekte
• Vorteile der Assoziation
  • Zukünftige Änderungen der assoziierten Klasse haben weniger Einfluss auf die gesamte Klassenhierarchie
  • Der Implementierungs-Overhead einer eigenen Klasse entfällt (Konstruktoren, überschriebene Methoden etc.)