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
