Circle-ellipse problem

from Wikipedia, the free encyclopedia

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 - Ellipseand from this the class in turn Kreis. There is already a method in the basic class that Zeichnedisplays the respective graphic element on the screen. It is quite conceivable that the methods SkaliereXand will be introduced SkaliereYin the class Ellipsein order to enable the user to subsequently adapt the semi-axes. Kreisas 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 Kreisno longer behaves as one Ellipsewould 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, Ellipsean additional method can be IstKreisprovided. 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 GrafischesElementused as the common base class , this has the disadvantage that common functionality must be implemented twice by Kreisand Ellipse, 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 OvalesElementintroduced, which GrafischesElementinherits from the superordinate base class Kreisand Ellipseserves 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 ( Kreisor Ellipse). The disadvantage is that the depth of the inheritance hierarchy is increased by the level of the additional (base) class OvalesElement.

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 Ellipseand Kreisis given.
This applies to swapping the direction of inheritance and renouncing specialization .
  • It is necessary to change the class of the instance from before Ellipseto after Kreis.
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 Kreisas 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

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