Jecel Assumpcao Jr a écrit :
> nicolas cellier wrote:
>> James Foster a écrit :
>>> On Nov 25, 2008, at 7:45 PM, Igor Stasenko wrote:
>>>> My understanding of inheritance is different, in short:
>>>> A subclass of particular class is a _specialization_ of base class,
>>>> not  _expansion_.
>>> In this context, I sometimes wonder if Square should inherit from 
>>> Rectangle (a specialization in which width and height are equal), or 
>>> Rectangle should inherit from Square (adding an instance variable). Am I 
>>> right that you would have Square inherits from Rectangle (Square being 
>>> more specialized)? But then it feels like we are wasting an instance 
>>> variable (since Rectangle would have two).
>> Beware, you're dangerously sliping to multiple inheritance because your 
>> Square might also be a lozenge :)
> 
> With the Rectangle as subclass of Square option this wouldn't be a
> problem - you would just have two different subclasses of Square.
> 
> Could Rectangle be a subclass of Square? Sure:
> 
> - Square instance variables: center, size, orientation
> 
> - Rectangle adds this instance variable: aspectRatio
> 

Following proposition does not seem to match what we learned at school

(Rectangle isKindOf: Square) -> true

But with a different POV, yes, a Rectangle isKindOf (degenerated) 
Square, a flatten one. So why not.

However, the question, apart inst vars is what methods/algorithm 
should/could be inherited. It seems to me that Square being a Rectangle 
could safely inherit all Rectangle methods. The reverse is not 
necessarily true, and this scheme would force to re-examine method by 
method which one to override because Square assumption is not true 
anymore (think of a method exploiting orthogonal diagonals properties 
for example). That is somehow fragile. Each time you add a method to 
Square, you must think in term of Rectangle or Lozenge... That breaks 
some kind of encapsulation no?

> We can make Ellipse a subclass of Circle using the same style. We can
> even have an #aspectRatio method in Square and Circle which always
> returns 1 and then we can move some of the more general code up in the
> classes hierarchy if we want to.
> 
> For raster graphics it is convenient to define Rectangles as always
> parallel to the screen axis so that just two points are enough to fully
> identify them. Perhaps calling them RasterRects instead would have made
> us think more clearly about them. We later moved to vector graphics
> (Balloon) but were stuck with the historic baggage.
> 
> -- Jecel
> P.S.: I am aware that even in this scheme you might want Parallelogram
> to inherit from both Rectangle and Lozenge (actually, Rhombus is more
> generic) and then you have the multiple inheritance problem again. Which
> is what Traits are for...
> 
> 
> 

Of course.

Nicolas