Kreis-Ellipse-Problem

Das Kreis-Ellipse-Problem ist ein „Beißknochen“ aus dem Bereich der objektorientierten Programmierung im Zusammenhang mit der Modellierung von Vererbungsbeziehungen. Einerseits ist ein Kreis eindeutig eine Ellipse, was dafür spricht, dass es sich um einen Subtyp der Ellipse handelt. Andererseits führt die Unterstützung einer nachträglichen, unabhängigen Veränderung der Länge der beiden Halbachsen, die für eine Ellipse sinnvoll sein kann, bei einem Kreis zu einem Problem, das häufig im Zusammenhang mit dem Liskovschen Substitutionsprinzip diskutiert wird.

Häufig wird dieser Fall in analoger Weise auch unter Verwendung von Quadrat und Rechteck diskutiert.

Beispiel

In einer typischen Klassenhierarchie zur Implementierung einer Grafiksoftware könnte von einer Basisklasse GrafischesElement – neben anderen Unterklassen  – die Klasse Ellipse abgeleitet werden und von dieser wiederum die Klasse Kreis. Bereits in der Basisklasse gibt es eine Methode Zeichne, die das jeweilige Grafikelement auf den Bildschirm darstellt. Nun ist durchaus denkbar, dass die Methoden SkaliereX und SkaliereY in der Klasse Ellipse eingeführt werden, um dem Benutzer die nachträgliche Anpassung der Halbachsen zu ermöglichen. Kreis als Spezialisierung der Ellipse erbt diese Methoden. Allerdings ist ein Kreis nach Anpassung nur einer der beiden Halbachsen kein Kreis mehr. Ein möglicher Ausweg aus diesem Dilemma wäre, bei einem Kreis bei Anpassung einer der Halbachsen die andere automatisch anzugleichen. Allerdings wäre dies ein Verstoß gegen das Liskovsche Substitutionsprinzip, da ein Objekt der Klasse Kreis sich nicht mehr verhält, wie man es für eine Ellipse erwarten würde.

Lösungsvorschläge

Hauptsächlich werden folgende Lösungsmöglichkeiten dieses Problems diskutiert:

• Spezifikation, dass die Größenanpassung fehlschlagen kann: Bereits auf Ebene der Ellipse wird vorgesehen, dass beim Methodenaufruf zur Änderung der Größe ein Scheitern der Operation möglich ist, was beispielsweise mittels eines Rückgabewerts kenntlich gemacht wird. Das Problem dieser und ähnlicher Abhilfemaßnahmen ist vor allem, dass eine solche Vorkehrung bereits auf Ebene der Basisklasse eingeführt werden muss, wo sie eigentlich unnötig ist. Verallgemeinert gesehen erfordert diese Lösungsvariante, dass die Entwickler der Basisklasse diesen Fall vorausahnen müssen, obwohl sie den konkreten Problemfall möglicherweise gar nicht kennen, da typischerweise Entwickler einer Basisklasse weder alle Anwendungsfälle ihrer Klasse kennen, noch mit den Entwicklern der spezialisierenden Klassen in Kontakt stehen.

• Vertauschen der Vererbungsrichtung: Diese Variante wurde in einer frühen, von Adele Goldberg entwickelten, Klassenbibliothek vom Prinzip her umgesetzt, und zwar war dort ein Rechteck als Spezialisierung eines Quadrats implementiert. Die Argumentation war, dass ein Rechteck zu einem Quadrat eine neue Eigenschaft ergänzt und zwar die Länge der anderen Seite. Z.B. in Java wird diese Semantik übernommen und durch das Keyword extends („erweitert“) indiziert. Kritisiert wird an dieser Implementierung, dass die Aussage „ein Rechteck ist ein Quadrat“ mathematisch widersinnig sei.^[1]

• Verzicht auf eine Spezialisierung für Kreis: Statt dessen kann in Ellipse eine zusätzliche Methode IstKreis vorgesehen werden. Der Nachteil dieser Variante ist, dass die Eigenschaften eines Kreises, die spezifisch für diesen sind und für eine Ellipse nicht gelten (beispielsweise der Radius), nicht in der Schnittstelle der Klasse untergebracht werden können. Der Vorteil ist, dass Ellipsen, die über eine nachträgliche Skalierung zu Kreisen werden, gleichberechtigt mit „richtigen Kreisen“ sind.
• Verzicht auf eine Vererbungsbeziehung: Keine der beiden Klassen erbt von der anderen sondern beide erben gleichberechtigt von einer gemeinsamen Basisklasse. Wenn als gemeinsame Basisklasse eine allgemeine Klasse (wie GrafischesElement) verwendet wird, hat diese Variante den Nachteil, dass gemeinsame Funktionalität von Kreis und Ellipse doppelt implementiert werden muss, das heißt, redundant ist.
• Erstellen einer Basisklasse: Keine der beiden Klassen erbt von der anderen sondern beide erben gleichberechtigt von einer gemeinsamen Basisklasse. Diese beherbergt möglichst alle Gemeinsamkeiten von Kreis und Ellipse. Redundante (d.h. doppelte) Implementierungen können somit vermieden werden.

Bewertung

Es lässt sich nicht unabhängig vom konkreten Anwendungsfall festlegen, ob Kreis sich als Spezialisierung von Ellipse eignet oder nicht. Im Wesentlichen hängt es davon ab, ob eine Ellipse nach Instanziierung in der Größe anpassbar sein soll oder nicht.

Literatur

• Charles F. Bowman: Wisdom of the gurus: a vision for object technology. Cambridge University Press, 1996, ISBN 0-13-499849-9

Einzelnachweise

1. ↑ B. Meyer: The many faces of inheritance: A taxonomy of taxonomy. In: IEEE Computer, Vol. 29, Seite 105–108, 1996