I think your basic point could be rephrased as this: "Object Oriented Design != inheritance and class heirarchies". This is a good point and well worth repeating. I've seen that a lot (especially newer) programmers want to solve every OO design question with inheritance, even when composition & delegation would be more natural.

I think one thing that might help would be first class delegation support in a language. I think there's a tendency to feel like inheritance is always okay because its been blessed into the language itself, whereas delegation is just a "hack".

On a sort of side note, I just read Chris Date & Hugh Darwen's "Third Manifesto" book (2nd edition), which is their response to two previous manifestos aiming to integrate relational theory and object oriented programming/design.

In the book, they outline a very detailed and well-defined model for inheritance. In their inheritance model, there are no such things as methods. Methods don't belong to a data type (class), they are just functions, with type dispatch based on the type of _all_ the arguments. The first argument is not special, unlike most OO implementations.

I really like their proposal, except for one thing. It's very data-oriented. If you're using inheritance because you're saying that two things represent a similar kind of data (they share set of properties), it works really well. They use geometrical figures as examples, so a circle inherits from an ellipse, for example. A circle and ellipse both represent similar data (geometric figures), but they don't necessarily have a lot of behavior. When you deal with them you're more interested in data (length of axes, placement on a plane, etc) than asking them to do things for you. And moreover, you want substitutability, so that anywhere you expect an ellipse, you can provide a circle.

OTOH, there are times when you want OO design in order to provide a common interface to multiple, often quite different, things. For example, if you were creating an RPG game, you might have lots of different objects that need to share some common behavior like "hit a creature". Each object may have fairly different sets of data describing the object, but you want to be able to wack things with them, so you give them a common interface.

All this is to set up my conjecture which is that maybe we should talk about two kinds of inheritance. For lack of a better word, one would be "behavior" inheritance (all objects must be able to "hit the thing") and the other "property" (data) inheritance (all objects must be able to tell me their weight in kilograms). With property inheritance, you don't care about behavior, but you want to be able to ask for certain information from all objects (weight, length, color, etc.).

Sometimes you need both, as in the "RPG object" example. But sometimes you might need only one or the other. I wonder if a language which separated the two might be useful.

In case it isn't clear, this relates to chromatic's piece because I think what I'm calling "behavior" inheritance is the same as chromatic's interface suggestion. My "data" inheritance would be more like object properties. In Perl, properties are not really distinguished from methods (behavior), but they could be!

BTW, if I'm describing some theory/language, pointers to it are welcome ;)