Axel Rogat

Objektorientiertes Programmieren mit C++ und JAVA

16.3: Generizitä: Beispiele

Kapitel 17

17.2: Ein erstes Beispiel

17.1 Einführung

Nachdem wir schon mehrfach über das Konzept der Vererbung allgemein gesprochen haben, wenden wir uns in diesem Kapitel ihrer Realisierung in C++ zu.

Wenn zwei oder mehrere Mengen (Klassen) gemeinsame Eigenschaften haben, sollte man diese abstrahieren und als eigenes Konzept formulieren. Nicht nur spart man sich dadurch die mehrfache Implementation; es werden so konsistente und einheitliche Schnittstellen geschaffen, die die Sicherheit und Erweiterbarkeit der Programme unterstützen.

Klassen entstehen durch die Abstraktion ähnlicher Verhaltensweisen von Objekten; Oberklassen entstehen durch die Abstraktion ähnlicher Verhaltensweisen von Unterklassen.

• Dabei werden in der abgeleiteten Klasse (Unterklasse) Daten und Funktionen aus der Oberklasse übernommen. Ein Objekt der Unterklasse enthält ein Objekt der Oberklasse ("anonymes Subobjekt" -- anonym, da es nicht als ganzes mit Namen angesprochen werden kann). Weitere Daten und Funktionen können hinzugefügt werden. Vom Speicher-Layout her können Objekte also höchstens größer werden.

• Außerdem dürfen Funktionen aus der Oberklasse in der Unterklasse neu definiert werden und überdecken dann die allgemeinere Version ("Überschreiben"). Man kann sogar gleichnamige Funktionen mit gleichen Parametertypen, aber einem anderem Rückgabetyp definieren, der die alte Funktion dennoch verdeckt.

• Es dürfen auch gleichnamige Datenmember definiert werden. Zu beachten ist aber, daß die Member der Oberklasse auf jeden Fall erhalten bleiben. Sie sind durch die Member der Unterklasse nur verdeckt.

Beispiel: Unser Beispiel aus Kapitel 1.1 beschäftigte sich mit geometrischen Figuren (z.B. für Computergrafik). Ein Quadrat ist ein spezielles Rechteck, und deshalb könnte man eine Klasse für Quadrate von einer Klasse für Rechtecke ableiten.

Es ist Geschmackssache, in welcher Richtung in solchen Diagrammen die Pfeile laufen. Die Unterklassen können als Teilmenge der Oberklasse aufgefaßt werden, so daß auch eine solche Pfeilrichtung Sinn macht. Der Ableitungsvorgang verläuft allerdings gerade umgekehrt, und so wollen wir unsere Pfeile auch zeichnen.

• Datenmember könnten die vier Eckpunkte in einem 2D-Koordinatensystem sein. Denkbare Operationen auf den Rechtecken wären zum Beispiel das Zeichnen auf dem Bildschirm, das Drehen und Verschieben, etc. -- einfach gehalten werden wir das später auch implementieren.

• Meistens ist es sicher sinnvoll, Quadrate als Rechtecke behandeln zu können. Bei bestimmten Operationen (z.B. Streckungen) muß man allerdings vorsichtig sein, da das Ergebnis nicht notwendigerweise mehr ein Quadrat (wohl aber ein Rechteck) ist. Die Operation "Streckung" sollte daher für Quadrat neu definiert werden und z.B. einen Fehler ausgeben.

• Die Vererbung ist nicht auf eine Ebene beschränkt -- die neu entstandenen Unterklassen können als Oberklasse einer weiteren Stufe verwendet werden, oder die verwendete Oberklasse war bereits Unterklasse in einer vorangegangenen Stufe.

Wir abstrahieren noch weiter und fassen ein Rechteck als Viereck auf -- Transformationen von Vierecken, die die rechten Winkel nicht erhalten, müssen wir dazu bei Rechtecken unterbinden (es wäre noch "Parallelogramm" als Zwischenstufe denkbar). In einer weiteren Stufe nach oben fassen wir Drei- und Vierecke allgemeiner als Polygone auf. In diesem Fall wäre es möglich, daß gar keine Datenmember hinzugefügt werden; die Eckpunkte könnten als (dynamisch angelegtes) Array bereits in "Polygon" festgelegt sein. Dafür sind die Operationen in den abgeleiteten Klassen eventuell nicht so effizient, als wären dort lokal nur die drei, bzw. vier benötigten Punkte abgelegt.

• Durch sukzessive Vererbung entsteht bereits eine Klassenhierarchie, deren Graph ein Baum ist. Die oberste Stufe einer solchen Hierarchie, die von keiner weiteren Klasse erbt, heißt Basisklasse.

• Abstraktionen, wie sie bei der Vererbung auftreten, ist man in der Mathematik beispielsweise beim Aufbau algebraischer Strukturen ganz selbstverständlich gewohnt, ohne daß der Vorgang dort so bezeichnet wird. Etwa ist eine Gruppe eine Halbgruppe und "erbt" alle Eigenschaften dieser Struktur. Zusätzlich besitzt sie noch ein neutrales Element, und es existieren Inverse bezüglich dazu. Ähnlich ist ein Ring eine abelsche Gruppe, besitzt aber eine zusätzliche Verknüpfung mit neutralem Element, etc.

  Da diese Vorgänge der Vererbung bei Klassen so ähnlich sind, verwundert es nicht, daß man sie einfach und elegant durch Klassenhierarchien darstellen kann, wie wir es in einem späteren Abschnitt auch tun werden.

  Ein leichter Unterschied liegt darin, daß es bei unserer Vererbung auch möglich ist, das Verhalten von einzelnen Operationen in der abgeleiteten Klasse gegenüber der Oberklasse zu verändern.

• An einem Vererbungsvorgang dürfen beliebig viele Oberklassen beteiligt sein. Die Objekte enthalten dann alle Member aus allen beteiligten Oberklassen und ggf. neue. (Es kann so zu Namenskonflikten kommen, die aber aufgelöst werden können.) Als Graph ergibt sich nicht notwendigerweise ein Baum, aber jedenfalls ein Graph ohne gerichtete Zykeln (DAG, directed acyclic graph). Wir werden uns zunächst nur mit einfacher Vererbung (von einer Oberklasse) beschäftigen.

• Bei den algebraischen Strukturen hat man beispielsweise folgenden Ausschnitt aus der Klassenhierarchie ("FieldScalars" steht für eine allgemeine Struktur für die Multiplikation von Vektoren mit Elementen aus einem Körper):
  

• Man darf ohne weiteres fremde Klassen (z.B. eben aus ggf. kommerziellen Klassenbibliotheken), deren Implementation nicht als Quelltext vorliegt, als Oberklasse verwenden und daraus eigene Klassen ableiten. Man profitiert dabei von einem hoffentlich vollständig entwickelten, sicheren und allgemein verwendbaren Datentyp.

• Auf den Unterschied zwischen Vererbung ("ist-ein") und Layering ("hat-ein") wurde schon eingegangen. Es ist auch wichtig, sich den Unterschied zu den Templates klarzumachen. Schablonen und Vererbung unterstützen beide die Wiederverwendbarkeit von Code, allerdings auf unterschiedliche Weise.

  Bei Schablonen wird auf der Ebene des Quelltextes, bei Vererbung auf der Ebene übersetzten Codes gearbeitet. Bei Schablonen gibt es völlig gleichartige Strukturen, die mit unterschiedlichen Typen arbeiten. Bei Vererbung wird mit den gleichen Typen gearbeitet, und die Strukturen werden erweitert oder leicht verändert. Wenn zwar mit unterschiedlichen Grundtypen und ähnlichen Operationen, aber völlig unterschiedlichen Realisierungen der Operationen gearbeitet wird, kann man keine Templates verwenden, sondern sollte nur die Schnittstellen vererben.