I think you may have mis-read my section groupings. If you re-read the document, I tried to make Inheritance one section, and then Delegation another section, then finally Interfaces and Traits under the Other section. I am not trying to describe everything in terms of inheritance.

Polymorphism is much, much more important than inheritance.

I am not trying to describe everything in terms of inheritance.

That may not be your aim, but that's precisely what your text does:

• The goal is not to mimic inheritance through delegation...
• Interfaces are not really inheritance per-say.

• (Regarding Traits and Roles) To use our single inheritance model:

  A Employee is-a Person.
  A Manager is an Employee who has managerial traits.

Framing the entire discussion in terms of inheritance has the unfortunate tendency of emphasizing the second of my two questions above at the expense of the (more important) first question.

I'd much prefer discussing each of these techniques in relation to those questions.

Personally I do not feel as if i am framing this all in terms of inheritance. But i will concede that it reads that way to you and probably to others as well.

I tend to prefer multiple-inheritance with heavy Interface Polymorphism, as it makes the most sense to me. But i fully realize that this is not the most common approach.

All that said, I would appreciate some suggestions from you, or others in ways to improve my delegation section in particular, as well as other sections you feel may be lacking.

In response to your critiques:

The goal is not to mimic inheritance through delegation...

Personally I felt this line pointed not to how delgation is like inheritance, but instead I strove to draw a distinction between the two. Maybe a rewording is in order here.

Interfaces are not really inheritance per-say.

While Interfaces are not strictly an inheritance related concept, in OOP they are most commonly associated with some form of an inheritance mechanism. So drawing a relation between the two was not a bad thing IMO.

(Regarding Traits and Roles) To use our single inheritance model:

In this I was actually refering back to the Person-Employee-Manager example when i mentioned the "Single Inheritance model". My goal here was not to show a linkage between Traits and inheritance, as i feel traits are closer to delegation, but instead to show the idea of traits within a familiar (already used) context. Here a rewording is definitly in order.

Framing the entire discussion in terms of inheritance has the unfortunate tendency of emphasizing the second of my two questions above at the expense of the (more important) first question.

I disagree with you here, not that your first question (What can this object do?) is the most important, but that inheritance emphasizes code reuse rather than polymorphism. I think it is the common opinion of those who sway towards delegation that inheritance is more about code-reuse. This I beleive is more a limitation of the (more common) single inheritance model and of some of the more popular langauges (especially the more strongly types ones (C++, Java, etc.)). Multiple inheritance is alot about "What can this object do?", and when mixed with Interface Polymorphism, it becomes even more so. I actually tend to feel that multiple-inheritance is much more akin to the philosophy of delegation than it is the more abstract and heady single-inheritance school.

There too is a difference between building an set of inherited classes yourself (or in a team/company), and inheriting other peoples classes (or from outside of your team/company). My feeling on foreign objects (those written by others) is they should be handled with delegation, so as to minimize un-intended effects. Once properly wrapped, I may then choose to inherit my wrapper class later on. There are of course exceptions, but there are always exceptions.

But i digress, my goal was not to discuss OOP/OOA/OOD in this level of detail. But to instead try and simplify some relatively complex ideas into short paragraphs for easy consumption, in the hopes that a common understanding/terminology would promote discussion.

Your suggestions for edits and re-wording are extremely welcome.

-stvn