Does it make sense to remove slots ?

[Tim Moore]

That's a pretty well-accepted object oriented design philosophy known 
as Liskov's Substitution Principle. It's actually often phrased in 
terms of "the circle/elipse problem" as a matter of fact.

Check out 
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.6
which as you can see is in a C++ FAQ, but really applies to object 
oriented design in general.

Also see http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple for some 
extended discussion.

Long story short: Todd is right. Circle shouldn't be derived from 
Ellipse unless they're both immutable, and most likely you don't really 
need a Circle type at all.

On Nov 7, 2004, at 2:48 PM, Todd Fleming wrote:

> Hi,
>
> I have a related question for people on this list. I have the 
> following philosophy about derivation and am curious if others here 
> believe the same way. If A inherits from B, and you are able to do X 
> with B, then you should also be able to do X with A. In this case, A = 
> Circle, B = Ellipse, X = squish. If you squish an ellipse, then you 
> still have an ellipse. If you squish a circle, then it's no longer a 
> circle. By squish, I mean scale, with x scale different from y scale.
>
> If you hold to this philosophy, and if your objects are mutable, then 
> Circle can't be derived from Ellipse, unless your Circle can turn back 
> into an Ellipse (yuck). If areas are considered immutable, then 
> squishing returns a new ellipse and my argument doesn't apply. I don't 
> know if Smalltalkers hold to this inheritance philosophy or not. I 
> also don't know if areas are considered mutable or immutable in the 
> library (I haven't looked closely at it).
>
> Now I have a question for you, Pupeno. Does Ellipse subsume all of the 
> functionality of Circle? If so, is Circle necessary?
>
> Another question: will Ellipse eventually support rotation?
>
> Todd
>
>
> Pupeno wrote:
>
>> I'm creating some objects for Ellipses and circles and I have the 
>> following code:
>>
>> Graphics addPrototype: #Ellipse derivedFrom: {Area}.
>> Ellipse addSlot: #center.
>> Ellipse addSlot: #xRadius.
>> Ellipse addSlot: #yRadius.
>>
>> Graphics addPrototype: #Circle derivedFrom: {Ellipse}.
>> Circle addSlot: #radius.
>> Circle removeSlot: #xRadius.
>> Circle removeSlot: #yRadius.
>>
>> c@(Circle traits) xRadius [ c radius ].
>> c@(Circle traits) xRadius: r [ c radius: r ].
>> c@(Circle traits) yRadius [ c radius ].
>> c@(Circle traits) yRadius: r [ c radius: r ].
>>
>> for me it makes sense since Circles are special cases of Ellipses 
>> where both radius are the same, so, whatever method I can apply to an 
>> Ellipse should be also available to Circle, except that a Circle can 
>> have only one radius. That's why I removed the slots, created another 
>> one, and then created accessors as if it was an Ellipse. Maybe the 
>> write accessors shouldn't be there.
>> Or, am I totally confused ? Does this make sense ?
>>
>
>
-- 
Tim Moore