inheritence vs composition

[preetam]

Hi,

This question is more towards design than towards c++ details.

By looking at books on design patterns and various google threads on
the same topic, I see that composition is favoured to inheritence. One
more article I read was Allen holub's "Why extends is evil".
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
One general advice I found was that - extending behaviour is better
done with interfaces and composition.

My question is - can we totally get rid of inheritence from concrete
classes ?

Because in all cases we can put common code in a class and use it by
containing an instance to it rather than subclassing it. Also I think
we do subclassing to get a modified behaviour and nothing else. The
only problem I see is few more lines of code. But the advantage is that
even the common code can be replaced at runtime by changing the
instance at runtime.

Is it a good idea if I almost never use subclassing for specializing
the base class, but just to get a interface.


Regards
Preetham

 

[Ulrich Achleitner]

Hi,

This question is more towards design than towards c++ details.

By looking at books on design patterns and various google threads on
the same topic, I see that composition is favoured to inheritence. One
more article I read was Allen holub's "Why extends is evil".
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
One general advice I found was that - extending behaviour is better
done with interfaces and composition.

My question is - can we totally get rid of inheritence from concrete
classes ?

"Why extends is evil": such a general statement is certainly wrong. one
always has to differentiate.

a very nice example of (even multiple) concrete subclasses is
building/extending/customising a class by deriving it from policy classes,
as suggested by Alexandrescu in "Modern C++ Design".

Because in all cases we can put common code in a class and use it by
containing an instance to it rather than subclassing it. Also I think
we do subclassing to get a modified behaviour and nothing else. The
only problem I see is few more lines of code. But the advantage is that
even the common code can be replaced at runtime by changing the
instance at runtime.

imho, this last suggestion comes close to Sutter's Pimpl-idiom (see "More
(?) Exceptional C++").

 

[davidrubin]

You will end up doing a lot more work. Consider the 'std::streambuf'
"protocol". It contains several protected virtual methods, which come
with default implementations. If you were just using interfaces, you
would have to implement every virtual method, even if just to delegate
to a default implementation.

I think, "Yes," you can replace inheritence form concrete classes with
inheritence from interfaces, but you lose a lot of convenience. (OTOH,
mayber there is a counterexample...) /david

 

[Ioannis Vranos]

Hi,

This question is more towards design than towards c++ details.

By looking at books on design patterns and various google threads on
the same topic, I see that composition is favoured to inheritence. One
more article I read was Allen holub's "Why extends is evil".
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
One general advice I found was that - extending behaviour is better
done with interfaces and composition.

My question is - can we totally get rid of inheritence from concrete
classes ?

Because in all cases we can put common code in a class and use it by
containing an instance to it rather than subclassing it. Also I think
we do subclassing to get a modified behaviour and nothing else. The
only problem I see is few more lines of code. But the advantage is that
even the common code can be replaced at runtime by changing the
instance at runtime.

Is it a good idea if I almost never use subclassing for specializing
the base class, but just to get a interface.

Let me give you a practical example on how I face inheritance in
application programming and perhaps you could provide me your alternative.


When I write .NET GUI applications I create a class MyForm: public Form,
which form contains:

http://msdn.microsoft.com/library/d...l/frlrfsystemwindowsformsformmemberstopic.asp


All its members are already defined in Form making it convenient to use
them directly, and we only add other components we need in our derived
class, like two Button *, one Label * and so on, which also have their
members defined.

And this is the case for all such component classes.



How could we substitute this approach with the one you are mentioning,
without a major impact in productivity and convenience?

 

[davidrubin]

Yes, convenience seems to be a driving factor. /david

 

[David White]

Hi,

This question is more towards design than towards c++ details.

By looking at books on design patterns and various google threads on
the same topic, I see that composition is favoured to inheritence. One
more article I read was Allen holub's "Why extends is evil".
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
One general advice I found was that - extending behaviour is better
done with interfaces and composition.

My question is - can we totally get rid of inheritence from concrete
classes ?

Without inheritance you have no polymorphism, unless you want to implement
it in a much less convenient way, but why would you want to do that? The
more objects you have (i.e., by using composition), the more potential
polymorphic behaviour you have if each object's type can be any one of a
number of different classes in a hierarchy, chosen at run-time. So, a
combination of both composition and inheritance can give you far more
flexible run-time behaviour than either one on its own.

DW

 

[red floyd]

imho, this last suggestion comes close to Sutter's Pimpl-idiom (see
"More (?) Exceptional C++").

Also known as the "Bridge" pattern (see GoF).

 

[preetam]

Thanks to all who responded.
Now I see why we can't totally remove inheritence.

In case of forms example above, I might endup delegating every single
method on Forms class. Aso the number of classes would be more. One
morre thing is the user has to call few set methods to change the
instance if needed. I might have a performence issue too.

But at the same time it gives more floxibility.

So there must be a nice balance between - performence, simplicity of
use/understanding, flexibility. It must be flexible but not at the cost
of making it too complex to understand and rewriting code. right..?