The well-known Circle-ellipse Problem states that, in the world of OO, a circle is not an ellipse because both entities do not behave the same: for instance, one can arbitrarily stretch an ellipse, but stretching a circle would break the essential property of this shape, namely that all its points are at the same distance from the center. On the other hand, other subtype relationships perfectly match the real-life scenarios they model: for instance, an assistant is certainly a kind of employee, and so an associated
Assistant type can be modeled as a subtype of
Employee without any problem whatsoever. What is the difference between these two modelizations that make the latter succeed where the former fails?
We introduce notation to talk about some concepts around the notion of "object" in OO. An object x has a definite lifetime T(x) = [t0,t1] during which the internal state of the object might (or might not) change according to the operations performed on it. We denote by S(x,t) the state of x at time t. Assume that we have a type
Ellipse modelling the mathematical concept of ellipse, which we can identify by the set E containing all the ellipses in R2: we intuitively expect from
Ellipse that the states of objects of this type can be univocally mapped to elements of E:
for all x of type
Ellipse, t in T(x), there is an ellipse e in E such that e ~ S(x,t),
or, put more succintly, we can say that
the states of
Ellipse objects are ellipses (modulo isomorphism).
Similarly, the states of
Circle objects are circles. A
Circle cannot be a subtype of
Ellipse because, according to Liskov Principle, a
Circle does not behave as an
Ellipse: there are mutable operations on
Ellipse (like the streching example mentioned at the beginning) such that the final state of the modifed object can never be a circle, so we cannot provide an equivalent operation for
Now, suppose we have types
Assistant: here the subtyping relationship works because all the state changes of an employee (salary raise, relocation, etc.) are compatible with the state changes of an assistant. And this points right to the crux of the matter: the real-life "employee" concept refer to a mutable entity whose state can change as part of the interactions of the employee with the rest of the company;
Employee models this concept by making the object state changes reflect the changes of the modelled employee:
the states of
Employee objects are employee states.
Confront this with
the states of
Ellipse objects are ellipses.
Ellipse states are ellipses, not ellipse states (ellipses do not have any mutable state). This is why the the subtypying relationship
Circle does not work while
Assistant does. In general, for a concept T < T' relationship to be representable by types
T', the states of
T' objects must model states of T and T' entities, respectively.