## Thursday, October 23, 2008

### Circles, ellipses, assistants and employees

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 `Circle`.

Now, suppose we have types `Employee` and `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 `Ellipse`/`Circle` does not work while `Employee`/`Assistant` does. In general, for a concept T < T' relationship to be representable by types `T` < `T'`, the states of `T` and `T'` objects must model states of T and T' entities, respectively.