Variable inheritance

[Carlos Ribeiro]

Oleg Broytmann wrote:
>   Easy. Think you are working with object of some classes. Let say there
>are Animals and ColorThings. Imagine us constructing Animals hierarchy:

This is *far* from a real situation. Your base classes are absolutely 
disjunct, and very close to abstract (not completely abstract because some 
implementation is provided, but not enough to make the base class useful on 
its own).

Most textbooks examples of MI are just like yours - simple but not 
realistic. For the most part, real classes are much more complex, and it is 
nearly impossible to have such clear and completely disjoint definitions. 
There (almost) always some overlap, leading to name clashes and other kinds 
of trouble.

The solution is to use mixins for all base classes. But in the end, the 
result is not very different than the ones achieved by aggregation. IMHO, 
aggregation leads to a cleaner approach.

There is also another subtle conceptual problem with the example that is 
very hard to deal with. Colors are not true "objects"; colors are 
attributes (or properties) of a given object and as such much more abstract 
in its nature than other objects. Its pretty common for objects to have 
several such attributes. Only when an attribute has some intrinsic behavior 
associated with it we could *realistically* talk about defining a class and 
then using multiple inheritance to build new classes with such *behavior* 
(not *attribute*).

One could argue that the meaning of  "objects" in programming is really so 
different from real world objects that such talk is nonsense. If so, the 
very meaning of "inheritance" in object oriented programming has to be 
rethought, because it is fundamentally based on our real world experience.


Carlos Ribeiro