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