Circle-ellipse problem
The circle-ellipse problem is a prominent, repeatedly discussed problem from the field of object-oriented programming in connection with the modeling of inheritance relationships . On the one hand , a circle is clearly an ellipse , which suggests that it is a subtype of the ellipse. On the other hand, the support of a subsequent, independent change in the length of the two semi-axes , which can be useful for an ellipse, leads to a problem with a circle that is often discussed in connection with Liskov's principle of substitution .
An analogous case is the relationship between square and rectangle .
example
In a typical class hierarchy for the implementation of graphics software , the class could be derived from a base classGrafischesElement
- in addition to other subclasses - Ellipse
and from this the class in turn Kreis
. There is already a method in the basic class that Zeichne
displays the respective graphic element on the screen. It is quite conceivable that the methods SkaliereX
and will be introduced SkaliereY
in the class Ellipse
in order to enable the user to subsequently adapt the semi-axes. Kreis
as a specialization the ellipse inherits these methods. However, after adjusting only one of the two semi-axes, a circle is no longer a circle. A possible way out of this dilemma would be to automatically adjust the other in a circle when one of the semi-axes is adjusted. However, this would be a violation of Liskov's substitution principle , since an object of the class Kreis
no longer behaves as one Ellipse
would expect it to.
Suggested solutions
The following possible solutions to this problem are mainly discussed:
- Failure specification for the size adjustment : Already at the level of the ellipse it is provided that when the method is called to change the size, a failure of the operation is possible, which is indicated, for example, by means of a return value. The main problem with these and similar remedial measures is that such a precaution must already be introduced at the level of the base class, where it is actually unnecessary. In general terms, this variant of the solution requires that the developers of the base class must anticipate this case, although they may not even know the specific problem, since developers of a base class typically neither know all use cases of their class nor are in contact with the developers of the specializing classes.
- Interchanging the direction of inheritance : This variant was implemented in principle in an early class library developed by Adele Goldberg , where a rectangle was implemented as a specialization of a square. The reasoning was that a rectangle to a square adds a new property and that is the length of the other side. The criticism of this implementation is that the statement “a rectangle is a square” is mathematically nonsensical.
-
Dispensing with a specialization for
Kreis
: Instead,Ellipse
an additional method can beIstKreis
provided. The disadvantage of this variant is that the properties of a circle that are specific to it and do not apply to an ellipse (for example the radius) cannot be accommodated in the interface of the class. The advantage is that ellipses that become circles through subsequent scaling have the same rights as circles that have been circles since construction.
-
No inheritance relationship : Neither of the two classes inherits from the other, but both inherit equally from a common base class. If a general class is
GrafischesElement
used as the common base class , this has the disadvantage that common functionality must be implemented twice byKreis
andEllipse
, that is, it is redundant . The aim should therefore be to accommodate as many of the similarities as possible in this common base class.
-
Extension of the inheritance hierarchy : A new (base) class is
OvalesElement
introduced, whichGrafischesElement
inherits from the superordinate base classKreis
andEllipse
serves as the base class for and . This new class only contains the properties that the two classes have in common. All non-common properties are defined in the respective derived class (Kreis
orEllipse
). The disadvantage is that the depth of the inheritance hierarchy is increased by the level of the additional (base) classOvalesElement
.
Comparison of the various proposed solutions
When changing the diameter in the X and / or Y direction to a value that is then the same, a distinction must be made between the following two cases:
- Direct conversion of the instance between
Ellipse
andKreis
is given.
- This applies to swapping the direction of inheritance and renouncing specialization .
- It is necessary to change the class of the instance from before
Ellipse
to afterKreis
.
- This applies to failure specification for size adjustment , waiver of an inheritance relationship, and expansion of the inheritance hierarchy .
rating
It cannot be determined independently of the specific application whether or not it is suitable Kreis
as a specialization Ellipse
. It essentially depends on whether or not an ellipse should be resizable after instantiation .
literature
- Charles F. Bowman: Wisdom of the Gurus: A Vision for Object Technology . Cambridge University Press, 1996, ISBN 0-13-499849-9
Individual evidence
- ^ B. Meyer: The many faces of inheritance: A taxonomy of taxonomy . In: IEEE Computer, Vol. 29, pages 105-108, 1996