Mehrfachvererbung

[Startseite]


Vorwort ] Voraussetzungen ] JAVA ] Implementierung von Klassen ] Erste Programme ] Klassenbibliothek ] Installation ] Applets ] Mehr JAVA ] Inside stiftUndCo ] Beispiele ] Downloads ]

Überladen von Methoden
Mehrfachvererbung
Multithreading
Netzwerktauglichkeit
Delegationsmodell der Ereignisbehandlung
Behandlung von Ausnahmen
Der Garbage Collector
Mehrfachvererbung/Interfaces

Beim Entwurf einer Klassenhierarchie stellt man des öfteren fest, daß eine Klasse im Grunde die Eigenschaften verschiedener Klassen in sich vereinigt. Damit liegt es nahe, die neue Klasse aus mehreren Vorgängerklassen abzuleiten. Dies nenn man "Mehrfachvererbung". Die Realisierung der Mehrfachvererbung wird nicht von allen objektorientierten Sprachen direkt unterstützt. C++ und Eiffel bieten sie, Object-Pascal und Oberon dagegen nicht. In Sprachen, die die Mehrfachvererbung nicht unterstützen greift man zu Hilfskonstruktionen, um die Mehrfachvererbung zu simulieren. Nachteil der Mehrfachvererbung ist, daß es zu unklaren Situationen kommen kann, etwa, wenn zwei Oberklassen über eine Methode gleichen Namens verfügen. Dann bleibt unklar, welche Methode von der Unterklasse geerbt wird. Dieses Problem wird in JAVA umgangen, indem dort eine Klasse nur eine konkrete Oberklasse haben darf aber mehrere abstrakte Oberklassen, die als "Interfaces" deklariert sind. Man spricht dann auch davon, daß die Klasse die Interfaces "implementiert". Wenn eine Klasse ein Interface implementiert, muß sie sämtliche im Interface deklarierten Methoden imlementieren. Bei Namensgleicheit von Methoden in Interfaces und Oberklasse kommt es also in jedem Fall zu einer eindeutigen Implementierung. Damit ist das genannte Problem gelöst. Andererseits stellt sich die Frage, was die Mehrfachvererbung unter JAVA denn überhaupt für Vorteile bringt, wenn die Oberklassen - mit einer Ausnahme - abstrakt sind, also keinerlei Funktionalität tragen. Nun der Vorteil liegt darin, daß die Objekte der Klasse als Objekte aller ihrer Oberklassen angesprochen werden können:

Beispiel:

Ein Programm zur Logiksimulation erfordert Bausteine, die einerseits logische Funktionen (Und, Oder, Nicht etc.) darstellen und zum anderen grafische Objekte sind.

class UndGatter implements GrafikObjekt, LogikGatter

/* UndGatter können nun als GrafikObjekt und als LogikGatter angesprochen werden */

Neben den Logik-Gattern gibt es noch weitere grafische Objekte, etwa Beschriftungen.

class Beschriftung implements GrafikObjekt

/* Beschriftungen sind GrafikObjekte */

Es gibt eine Reihe von Situationen, in denen diese grafischen Objekte in ähnlicher Weise behandelt werden, beispielsweise könnte es eine Methode geben, die einem grafischen Objekten den Auftrag schickt, sich neu darzustellen.

update(GrafikObjekt g)

Dieser Auftrag kann in gleicher Weise auf UndGatter und Beschriftungen angewendet werden.

Spezifische Methoden zum Umgang mit den Logikbausteinen können speziell auf diese angewendet werden.

Es ist auch bei der Anwendungsentwicklung durchaus möglich, daß die Darstellungsaspekte und die Verwaltung der Logikauswertung einer Schaltung von unterschiedlichen Teams bearbeitet wird, die jeweils nur die Funktionalität der entsprechenden Schnittstellenimplementierung berücksichtigen müssen.

 

 


Seitenanfang

© Georg Dick