structural inheritance bad?

D

davidrubin

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
 
D

davidrubin

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?
 
A

Adios

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

http://www.itworld.com/AppDev/710/lw-02-stroustrup/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?
 
M

mwigdahl

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
 
J

Jesper Madsen

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.
 
A

Andrey Tarasevich

mwigdahl said:
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.
 
A

Andrey Tarasevich

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,270
Messages
2,571,353
Members
48,041
Latest member
Oliwen826

Latest Threads

Top