imported>AX29: Änderungen von ~2025-27300-56 (Diskussion) auf die letzte Version von Cactus26 zurückgesetzt

2025-10-01T09:04:27Z

Änderungen von ~2025-27300-56 (Diskussion) auf die letzte Version von Cactus26 zurückgesetzt

Neue Seite

Das '''Kreis-Ellipse-Problem''' ist ein prominentes, wiederholt diskutiertes Problem aus dem Bereich der [[Objektorientierte Programmierung|objektorientierten Programmierung]] im Zusammenhang mit der [[Objektmodell|Modellierung]] von [[Vererbung (Programmierung)|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 [[Große Halbachse|Halbachsen]], die für eine Ellipse sinnvoll sein kann, bei einem Kreis zu einem Problem, das häufig im Zusammenhang mit dem [[Liskovsches Substitutionsprinzip|Liskovschen Substitutionsprinzip]] diskutiert wird.

Ein analoger Fall ist die Beziehung zwischen [[Quadrat]] und [[Rechteck]].

== Beispiel ==
In einer typischen Klassenhierarchie zur Implementierung einer [[Grafiksoftware]] könnte von einer [[Basisklasse]] <code>GrafischesElement</code> – neben anderen Unterklassen – die Klasse <code>Ellipse</code> abgeleitet werden und von dieser wiederum die Klasse <code>Kreis</code>. Bereits in der Basisklasse gibt es eine [[Methode (Programmierung)|Methode]] <code>Zeichne</code>, die das jeweilige Grafikelement auf den Bildschirm darstellt. Nun ist durchaus denkbar, dass die Methoden <code>SkaliereX</code> und <code>SkaliereY</code> in der Klasse <code>Ellipse</code> eingeführt werden, um dem Benutzer die nachträgliche Anpassung der Halbachsen zu ermöglichen. <code>Kreis</code> 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 [[liskovsches Substitutionsprinzip|liskovsche Substitutionsprinzip]], da ein Objekt der Klasse <code>Kreis</code> sich nicht mehr verhält, wie man es für eine <code>Ellipse</code> erwarten würde.

== Lösungsvorschläge ==
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.<ref name="Meyer1996">B. Meyer: ''The many faces of inheritance: A taxonomy of taxonomy''. In: IEEE Computer, Vol. 29, Seite 105–108, 1996.</ref>

*''Verzicht auf eine Spezialisierung'' für <code>Kreis</code>: Stattdessen kann in <code>Ellipse</code> eine zusätzliche Methode <code>IstKreis</code> 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 (Objektorientierung)|Schnittstelle]] der Klasse untergebracht werden können. Der Vorteil ist, dass Ellipsen, die über eine nachträgliche Skalierung zu Kreisen werden, gleichberechtigt zu Kreisen sind, die seit Konstruktion solche 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 <code>GrafischesElement</code> verwendet wird, hat das den Nachteil, dass gemeinsame Funktionalität von <code>Kreis</code> und <code>Ellipse</code> doppelt implementiert werden muss, das heißt, [[Redundanz (Informationstheorie)|redundant]] ist. Um diese Redundanz zu vermindern, könnte ein [[Mixin]] verwendet werden, falls die Sprache so etwas unterstützt.

== Bewertung ==
Es lässt sich nicht unabhängig vom konkreten Anwendungsfall festlegen, ob <code>Kreis</code> sich als Spezialisierung von <code>Ellipse</code> eignet oder nicht. Im Wesentlichen hängt es davon ab, ob eine Ellipse nach [[Objekt (Programmierung)#Instanziierung|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 ==
<references />

[[Kategorie:Objektorientierte Programmierung]]

Kreis-Ellipse-Problem - Versionsgeschichte

imported>AX29: Änderungen von ~2025-27300-56 (Diskussion) auf die letzte Version von Cactus26 zurückgesetzt