Re: Clean Object Class Design -- Circle/Ellipse

Bob Badour wrote:
> I find it very telling that almost every OO pundit has found it necessary to
> write an apologia explaining why the very real and natural subtype/supertype
> relationship between circle and ellipse does not apply in OO.

But it does apply. If we model the *mathematical* concept of an ellipse as an Ellipse class in OO, then there is no problem whatsoever doing the same with Circle, and preserving the *mathematical* sub-type relation as an OOP subclass relation. The very real and natural subtype/supertype relationship between circle and ellipse does indeed apply in OO.

Where things go wrong is when people try to add the notion of procedural state. This seems incredibly easy and natural in programming terms, since we're all used to arrays, records, objects etc. and their associated operations. But it is NOT normal mathematics. The maths you need to handle values that are mutable states is VERY tricky and does not follow directly from the simple notions of types/sub-types or sets/sub-sets.

The Circle/Ellipse issue is nothing more than a coincidence. Circles and Ellipses are simple enough for anyone to get an intuitive grasp of. This misleads them into thinking that they understand the maths, or that they understand the OOP, or that they understand both. Worse still, it misleads them into thinking they understand the connection (or lack thereof) between the OOP and the maths.

Most OOP areas we work with don't have coincidences of terminology with simple maths, so we don't get fooled into thinking we're dealing with simple mathematical models.

I find it very telling that almost every OO critic has found it necessary to attack OO on the basis that its modelling of procedural, mutable state does not work exactly like the simple mathematics of functional values.