Circle-ellipse problem

The circle - ellipse problem is a " Beißknochen " from the field of object-oriented programming in the context of 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 variation in the length of the two semi-axes, which can be useful for an ellipse in a circle to a problem that is often discussed in connection with the liskovschen substitution principle.

Frequently, this case will be discussed in an analogous manner using square and rectangle.

Example

In a typical class hierarchy to implement a graphics software could from a base class graphic element - in addition to other sub- classes - the class ellipse are derived and, from this, the class circle. Already in the base class there is a method Draw, which represents the respective graphic element on the screen. Now it is quite conceivable that the methods SkaliereX and SkaliereY be introduced in the Ellipse class to allow the user to retroactive adjustment of the half- axes. Circle as a specialization of the ellipse inherits these methods. However, a circuit in accordance with adjustment of only one of the two half-shafts is no longer a circle. A possible way out of this dilemma would be to the other to equalize automatically when a circle at adapting one of the semi-axes. However, this would be a violation of the Liskov substitution principle, as an object of class Circle does not behave as you would expect for an ellipse.

Solutions

Mainly these possible solutions to this problem are discussed:

• Specification that the sizing may fail: Already at the level of the ellipse is provided that, when the method call to change the size a failure of the operation is possible, which is indicated for example by means of a return value. The problem with this and similar remedies is mainly that such a provision should be introduced at the level of the base class already, where it is actually unnecessary. Seen generalize this solution requires version that the developers of the base class must anticipate this case, even though they may not know the specific case of a problem, since typically the creator of one base class either all applications in its class know, nor with the developers of specializing classes are in contact.

• Reversing the Direction of inheritance: This variant was developed at an early, by Adele Goldberg, class library implemented in principle, namely a rectangle was implemented as a specialization of a square there. The reasoning was that a rectangle to a square added a new property and that the length of the other side. Another criticism of this implementation is that the statement " a rectangle is a square " is mathematically absurd.

• Waiver of a specialization for loop: Instead, it can be provided at an additional method IstKreis ellipse. The disadvantage of this variant is that the properties of a circle, which are specific to them and are not of an ellipse (such as the radius), can not be accommodated in the interface of the class. The advantage is that ellipses on a subsequent scaling to circles on an equal footing with the "right circles " are.
• Renunciation of an inheritance relationship: Both classes inherit from the other but both inherit equally from a common base class. If a common base class, a general class ( such as graphical element ) is used, which has the disadvantage that common functionality of the circle and the ellipse must be implemented twice, that is, is redundant. It should therefore be sought to accommodate as much of the similarities in this common base class.

Assessment

It can not be set independently on the specific application, whether circuit is suitable as a specialization of the ellipse or not. In essence, it depends on whether an ellipse after instantiation of the variable is to be adjustable or not.