Kreis-Ellipse-Problem

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

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[Bearbeiten]

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[Bearbeiten]

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

  • Fehlschlagspezifikation für die Größenanpassung: 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. Kritisiert wird an dieser Implementierung, dass die Aussage „ein Rechteck ist ein Quadrat“ mathematisch widersinnig sei.[1]
  • Verzicht auf eine Spezialisierung für Kreis: Stattdessen 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 GrafischesElement verwendet wird, hat das den Nachteil, dass gemeinsame Funktionalität von Kreis und Ellipse doppelt implementiert werden muss, das heißt, redundant ist. Es sollte also angestrebt werden, in diese gemeinsame Basisklasse möglichst viele der Gemeinsamkeiten unterzubringen.
  • Erweiterung der Vererbungshierarchie: Es wird eine neue (Basis-)Klasse OvalesElement eingeführt, die von der übergeordneten Basisklasse GrafischesElement erbt und als Basisklasse für Kreis und Ellipse dient. Diese neue Klasse enthält nur die Eigenschaften, die die beiden Klassen gemeinsam haben. Alle nicht gemeinsamen Eigenschaften werden in der jeweiligen abgeleiteten Klasse (Kreis bzw. Ellipse) definiert. Nachteil ist die Erhöhung der Tiefe der Vererbungshierarchie um die Ebene der zusätzlichen (Basis-)Klasse OvalesElement.

Vergleich der verschiedenen Lösungsvorschläge[Bearbeiten]

Bei einer Änderung der Durchmesser in X- und/oder Y-Richtung auf einen danach gleichen Wert sind die folgenden beiden Fälle zu unterscheiden:

  • Direkte Umwandlung der Instanz zwischen Ellipse und Kreis ist gegeben.
Dieses gilt für Vertauschen der Vererbungsrichtung und Verzicht auf eine Spezialisierung.
  • Änderung der Klasse der Instanz von zuvor Ellipse auf danach Kreis ist erforderlich.
Dieses gilt für Fehlschlagspezifikation für die Größenanpassung, Verzicht auf eine Vererbungsbeziehung und Erweiterung der Vererbungshierarchie.

Bewertung[Bearbeiten]

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[Bearbeiten]

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

Einzelnachweise[Bearbeiten]

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