Re: Composition versus Implementation Inheritance
chsalvia@gmail.com wrote:
I suppose I tend to think that, from a design point of view, if it
doesn't make any sense to instantiate a certain class outside of
another class, than this should be reflected somehow in the code, e.g.
by having a protected constructor.
It's true that you can never anticipate all the future requirements of
developers down the road, but doing so would not really limit
extensibility, because a future develop can always use private
inheritance if they want to extend the class.
Which defeats the purpose of making the constructor protected, so why
bother?
The fact is, we have a class that has already been used in two contexts,
why assume that it wouldn't be useful in any others?
On the other hand, we are talking about a class that is not documented
and therefore cannot be expected to perform in any particular way so
anyones use of that class outside of those two contexts is hazardous.
You are asking here why use composition over private inheritance. How
about we turn the question around, why use private inheritance over
composition? Now that question has a solid answer, there are things that
you can do with private inheritance that you simply can't do with
composition, and if you need or want to do those things, then private
inheritance is what you use.
So now we can ask your original question again. If we are not using the
features that private inheritance provides, then we are telling
developers something about our class by no using private inheritance.
Composition sends a message to anyone looking at the class, "don't
bother worrying about me doing x, or y because that can't be done with a
composition relationship.