Re: Clean Object Class Design -- Circle/Ellipse

From: Bob Badour <bbadour_at_golden.net>
Date: 17 Oct 2001 17:49:34 -0700
Message-ID: <cd3b3cf.0110171649.7dae1983_at_posting.google.com>


Graham Perkins <gperkins_at_dmu.ac.uk> wrote in message news:<3BB8485E.41A7EE55_at_dmu.ac.uk>...
> 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.

Procedural state applies to variables and not to values. If the language makes sufficient distinction between variables and values, nothing goes wrong.

> But it is NOT normal mathematics.

Really? What was all that x, y and z stuff back in ninth grade algebra? What were all those boundary conditions when solving systems of differential equations?

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

As long as a variable contains a value, that value is a mutable state. (ie. value equates to state and variables are mutable.) One changes the state of the variable by replacing the value with a different value.

> The Circle/Ellipse issue is nothing more than a coincidence. Circles
> and Ellipses are simple enough for anyone to get an intuitive grasp
> of.

Which is what makes the Circle/Ellipse paradigm (example) interesting and useful for exploring the issues.

> This misleads them into thinking that they understand the maths,
> or that they understand the OOP, or that they understand both.

I have not seen any indication that the OO apologists misunderstand the maths. If these OO pundits do not understand OOP, then I am afraid nobody does.

> Worse
> still, it misleads them into thinking they understand the connection
> (or lack thereof) between the OOP and the maths.

Isn't it simpler to observe that the OO apologists prefer to project the shortcomings of their creations onto something else? Denial is an entirely natural human response.

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

Really? You don't work with addition, subtraction, successor, predecessor, expression, function or relation? No logic? No algebra? No number? No graphs? No geometry? No domain? No range? No dimension? No units? What do you work with?

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

What OO critic? Where? I have not seen many criticisms of OO, and I have never seen a criticism of OO based on mutable state vs. functional value. My own criticisms are directed at specific languages and not at OO itself.

Any criticisms I have seen directed at OO are based on the lack of any rigorous or even consensus definition of OO and on the resulting ad hoc hodge podge of conflicting beliefs. Received on Thu Oct 18 2001 - 02:49:34 CEST

Original text of this message