Re: Clean Object Class Design -- Circle/Ellipse

D_at_B.A wrote:

> In article <9TF57.167$%16.43276332_at_radon.golden.net>, Bob Badour says...
> >
> >>>>>I see that Chris Date recently published an excellent article on the
> >>>>>circle/ellipse issue at http://www.dbdebunk.com/
> >>>>>
> >>>>Excellent? Just a terminology assault; I personally learned nothing from
 this
> >>>>article.
> >>>
> >>>Could your dismissal of the article as a terminology assault have
> >>>contributed to your failure to learn anything?
> >>
> >>If you advocate rigorous models, what did you found so attractive about the
> >>article? Does it establish one?
> >
> >Yes.
> >
> >
> >>Does it explain LSP paradox?
> >
> >It obviates it by further clarifying what LSP really means. Was it required
> >to explain it as well?
> >
>
> I must admit that I judged the article upon it's ability to answer a set of
> questions I have in mind, which is not quite fair. Here it is:
>
> 1. Is the case Square/Rectangle really similar to Circle/Ellipse?
> i. What methods/operations in Rectangle signature would make it different from
> Ellipse? If they are identical from signature perspective, then, maybe,
> Rectangle and Ellipse are just 2 different implementations of same type?
>
> I know, that the suggestion that Rectangle and Ellipse are the same type is
> absurd, but the only way to reject it as such is to establish a formal model. A
> recent thread where object behaviour has been interpreted within group theory
> does this. Class hierarchy is interpreted just as a subgroup lattice. Group
> interpretation, however, prescribes in advance what class hierarchy is,
> something that is hard to swallow, especially if one thinks that a user can
> extend a class and override behaviour in a way that has not been anticipated by
> class designers.
>
> ii. Is there a method in Square/Rectangle case that one might want to override
> for performance reasons? It seems to me that we don't need to introduce Square
> type at all.

Chris Date would be well advised to take some time of from work and go to a summer camp
(functional programming camp that is). Hopefully, that would broaden his horizons beyond the world of data and read/update operations.

Yes, the type <CIRCLE> is a subtype of <ELIPSE>, because both types define no operations,
just two sets, the first being a proper subset of the latter.

In order to say anything about relationship between CIRCLE-ALGEBRA = <CIRCLE, C-OP> and ELIPSE-ALGEBRA = <ELIPSE, E-OP>, we would have to provide formal specifications of each operation in C-OP and E-OP.

Since people are having trouble agreeing what operations are reasonable for circles and elipses, here is a cleaner example:

Let I be the set of integers and R of reals. I is a subset of R (we are talking abstract types, not machine implementations - Date's data independence).
Now consider algebras IA = <I, {+,*}> and RA = <R, {+,*}>, with the standard interpretation (specification) of summation and multiplication. Is IA a subtype of RA? Chris Date would have you believe so. But RA is a field, whereas IA is only a ring (and thus does nort preserve all properties of RA).
In conclusion, we can't substitute integerobjects for realobjects in all programs written using realobjects,
and if we try, some of these programs will break (namely these that rely on x * 1/x = 1).

Note that this has nothing to do with update operations; when we send a message op(x) to a number y, y does not change, but simply returns another constant z = op(x,y).

Marc Gluch
Mindtap Inc. Received on Sat Jul 21 2001 - 08:12:40 CEST