Re: Clean Object Class Design -- Circle/Ellipse

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?
2. 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. Received on Thu Jul 19 2001 - 21:43:44 CEST