By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,171 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

structural inheritance bad?

P: n/a
Structural inheritance (inheriting implementation) is equivalent to
composition in that a particular method must either call 'Base::foo' or
invoke 'base.foo'. Apparantly, The Literature tells us to prefer
composition over inheritance. Can anyone provide some reasons why this
is the case (based on "real-world" experience)? For example, is
structural inheritance more difficult to maintain? More difficult to
test? Have a larger impact on compile time? Not lend itself well to
re-use? Thanks. /david

Jul 23 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
* da********@warpmail.net:
[muddling oop thoughts]


OT.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #2

P: n/a
I see, clc++ is like physics: it only answers "how", never "why".

Let me try again: what are the implications of using structural
inheritance versus composition in a large C++ project?

Jul 23 '05 #3

P: n/a
da********@warpmail.net wrote:
I see, clc++ is like physics: it only answers "how", never "why".

Let me try again: what are the implications of using structural
inheritance versus composition in a large C++ project?


I think you are looking for some "silver bullet". Check this article
regarding "silver bullets":

http://www.itworld.com/AppDev/710/lw...up/page_1.html


--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #4

P: n/a
Ioannis Vranos wrote:
da********@warpmail.net wrote:
I see, clc++ is like physics: it only answers "how", never "why".

Let me try again: what are the implications of using structural
inheritance versus composition in a large C++ project?


I think you are looking for some "silver bullet". Check this article
regarding "silver bullets":

http://www.itworld.com/AppDev/710/lw...up/page_1.html


[Q. what would you lie to see added to the standard?]

Bjarne Stroustrup:
GUI: It would be nice to have a standard GUI framework, but I don't see how
that could be politically feasible.
Platform-independent system facilities: I'd like to see the Standard
Library provide a broader range of standard interfaces to common system
resources (where available), such as directories and sockets.

Hey no fair Stroustrup! What would be left for old Dead Dick Vic to moan
about?
Jul 23 '05 #5

P: n/a
This article does not seem to address my question in the slightest, but
thanks.

Jul 23 '05 #6

P: n/a
Structural inheritance is fine if your design respects the LSP (Liskov
Substitution Principle) -- basically, that all operations that operate
on base-class objects can have derived-class objects substituted and
operate correctly. Composition is safer in that it doesn't inherently
advertise LSP conformance, although you tend to type more. :)

I have found that the problem is that although it is fairly easy to
design hierarchies respecting the LSP at the start of a large project,
modifications made in midstream have a good chance of causing LSP
violations if your relationships really shouldn't have been "IS-A" to
begin with, leading to either kludges or extensive refactoring. YMMV.

More info on the LSP:
http://www.objectmentor.com/resources/articles/lsp.pdf

Matt

Jul 23 '05 #7

P: n/a

<da********@warpmail.net> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
Structural inheritance (inheriting implementation) is equivalent to
composition in that a particular method must either call 'Base::foo' or
invoke 'base.foo'. Apparantly, The Literature tells us to prefer
composition over inheritance. Can anyone provide some reasons why this
is the case (based on "real-world" experience)? For example, is
structural inheritance more difficult to maintain? More difficult to
test? Have a larger impact on compile time? Not lend itself well to
re-use? Thanks. /david


If you inherit to add functionality, the child needs to #include the parent
in the header.
If you add functionality by aggregating, you can choose to just add a
pointer to the class.
The benefit of this would be, that you have isolated the knowledge to the
cpp files that
uses the header. It is worth a lot, when you are working on large projects.
Jul 23 '05 #8

P: n/a
mwigdahl wrote:
Structural inheritance is fine if your design respects the LSP (Liskov
Substitution Principle) -- basically, that all operations that operate
on base-class objects can have derived-class objects substituted and
operate correctly. Composition is safer in that it doesn't inherently
advertise LSP conformance, although you tend to type more. :)


Huh? OP is talking about inheritance that does not implement the IS-A
relationship. There's abosolutely no requirement for this type of
inheritance to satisfy LSP. LSP is simply not applicable to this type of
inheritance.

--
Best regards,
Andrey Tarasevich
Jul 23 '05 #9

P: n/a
da********@warpmail.net wrote:
Structural inheritance (inheriting implementation) is equivalent to
composition in that a particular method must either call 'Base::foo' or
invoke 'base.foo'. Apparantly, The Literature tells us to prefer
composition over inheritance. Can anyone provide some reasons why this
is the case (based on "real-world" experience)? For example, is
structural inheritance more difficult to maintain? More difficult to
test? Have a larger impact on compile time? Not lend itself well to
re-use?


There are absolutely no serious problems with this type of inheritance
as long as it is implemented through private inheritance. Although it is
worth pointing out that aggregation (as opposed to inheritance) is in
general case more flexible. It is possible to aggregate several
instances of the same class, if necessary. You can also give a
meaningful name to the aggregated object, which makes the program more
readable. Neither is possible is case of inheritance. Whether all this
really makes a noticeable difference depends on the concrete situation.

However, sometimes in C++ language one has to employ _public_ structural
(i.e. non-IS-A) inheritance in order to use certain convenient and
well-established implementational techniques. This is often frowned upon
because the popular belief is that public inheritance in C++ shall only
be used to implement IS-A relationships (LSP, etc.). I personally don't
agree with this view of public inheritance in C++ (or, more precisely, I
consider it to be unnecessarily extreme), but don't be surprised if you
meet someone who does.

--
Best regards,
Andrey Tarasevich
Jul 23 '05 #10

P: n/a
Yes, I reread (slower, this time) and you are right. Sorry!

Matt

Jul 23 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.