Talk:Composition over inheritance
|WikiProject Computer science|
"Using inheritance we either have to do multiple inheritance, which is bad,[vague]"
Why is it bad? Use multiple inheritance for the example given (using mix-in classes) seems like a much more conceptually cleaner way to do it. Is this referring to some performance/gotcha specific to C++.
This article doesn't outline a clear argument against multiple inheritance (specifically mix-ins), and reeks of opinion.
Also it seems to be very biassed to statically typed languages (C++).
For example in dynamic language (such as Python, Perl, etc) duck typing would be a much more appropriate solution to the example given.
It's not even clear in the C++ example why supplying delegate classes is any better than just defining the methods for each of the sub-interfaces (Visibility, Update, Collision) and using single inheritance. — unsigned comment by 126.96.36.199 on 2011-03-12
[the article] C++ and C# code snippets, even if of some use to those familiar with the languages, don't help others to understand this concept at all better. — Preceding unsigned comment added by 188.8.131.52 (talk) 22:27, 16 January 2013 (UTC)
I started off writing that just the diagram was confused but have come to the conclusion that whole article is.
Is the article trying to explain that 'HAS-A can be better than IS-A' or is it trying to explain that 'many narrow interfaces can be better than a single broad interface'?
From the title, it should surely be about the former, but it certainly seems to blur into the latter in places (without identifying when it is crossing the line...).
As for the diagram... it shows (by inheritance arrows) that a Duck IS-A Quackable and (transitively) IS-A Flyable, whereas the point of p.22..23 of Head First Design Patterns on which this diagram is based is that 'HAS-A can be better than IS-A'.
Conversely the diagram does not actually depict the HAS-A relaionship in a clear exemplary way at all.
What the diagram's author has done is make Duck inherit from (implement the interfaces of) Flyable and Quackable (whereas the Head First Design Patterns book does not do so). And by doing this the diagram confuses rather than clarifies the distinction betwen IS-A and HAS-A - because the diagram actually depicts that a Duck both IS-A and HAS-A Flyable and Quackable behaviour.
This is likely to confuse rather than aid understanding, I think.
Note that the code examples do not do the same thing - the composite does not inherit the interfaces of it's components. However the fact that it ends up with a series of single line 'forwarding' calls might make the reader wonder whether it might not be better if it did...
Suggested resolution: identify/segregate and reference the 'Interface segregation principle' wherever the article is in fact talking about it.