Inheritance and function reuse - why is it bad?

[Grumpy Willis]

I'm interested to learn why use of inherited functions are frowned upon, and
indeed why it is allowed in a language at all if it *is* frowned upon.

[Alan Gauld]

Post by Grumpy Willis
I'm interested to learn why use of inherited functions are frowned upon, and
indeed why it is allowed in a language at all if it *is* frowned upon.

It is not the use of inherited functions that is frowned upon -
indeed that sould be encouraged! What is discouraged is using
inheritance as a mechanism for function re-use (with the possible
exception of mixin style programming in dynamic languages).

Inheritance is intended to provide an "is-a" relationship where
the subclass displays the same interface and general semantics to
the superclass (a shape heirarchy, or set of bank accounts to use
sopme comon examples). But just because a class C has a method
m() that we would like to use in our class that is not a good
enough reason to define our class as a subclass of C. We should
only do that is our class truly is-a kind of C. Otherwise we are
better creating a C as an attribute and using delegation to
access the desired method m().

However if our class really is-a C. Then by all means inherit
from C and allow users to call m via inheritance. Equally you can
extend m() slightly in your class but call the inherited version
to suipllement your own version of m - this, indeed, is usually
how inherited methods are overridden.

HTH,

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

[Grumpy Willis]

Post by Alan Gauld
Inheritance is intended to provide an "is-a" relationship where
the subclass displays the same interface and general semantics to
the superclass (a shape heirarchy, or set of bank accounts to use
sopme comon examples). But just because a class C has a method
m() that we would like to use in our class that is not a good
enough reason to define our class as a subclass of C. We should
only do that is our class truly is-a kind of C. Otherwise we are
better creating a C as an attribute and using delegation to
access the desired method m().

Ah thanks, that's cleared up one of those moments where the universe looks
all bent out of shape!

Ta,
GW.

[Ilja Preuß]

Post by Grumpy Willis
I'm interested to learn why use of inherited functions are frowned
upon, and indeed why it is allowed in a language at all if it *is*
frowned upon.

Inheritance is often badly misused, especially by beginners. It's still a
very powerfull tool when used wisely. Articles which seem to imply that
inheritance is frowned upon are just overreactions to the former fact, in my
humble opinion.

Take care, Ilja

[Isaac Gouy]

Post by Ilja Preuß

Post by Grumpy Willis
I'm interested to learn why use of inherited functions are frowned
upon, and indeed why it is allowed in a language at all if it *is*
frowned upon.

Inheritance is often badly misused, especially by beginners. It's still a
very powerfull tool when used wisely. Articles which seem to imply that
inheritance is frowned upon are just overreactions to the former fact, in my
humble opinion.

As you say, there are a range of viewpoints ;-)

"A Use for Inheritance" Andrew Black
http://www.cs.jyu.fi/~sakkinen/inhws/papers/Black.pdf

"Inheritance is Specialisation" Mads Torgersen
http://www.cs.jyu.fi/~sakkinen/inhws/papers/Torgersen.pdf

[H. S. Lahman]

Responding to Willis...

Post by Grumpy Willis
I'm interested to learn why use of inherited functions are frowned upon, and
indeed why it is allowed in a language at all if it *is* frowned upon.

It is frowned upon for a couple of reasons. If subclasses can override
the behaviors, then it opens a Pandora's Box of opportunities for
foot-shooting. While the problem is greatly reduced if overrides are
not allowed, it still exists. Basically the problem is that if the tree
is reorganized, it is possible to break existing clients of superclasses
because the concrete behavior they expected is no longer provided.

Another reason is that it complicates maintenance of generalizations.
The OO is-a relation is already difficult to modify because it is a
static structure and a client accessing a superclass depends on the
structure of the /whole/ tree. By adding implementation inheritance one
complicates making safe updates. In effect one adds another dimension
(the others being interface and data inheritance) that must be
synchronized during maintenance. In particular, such trees are
especially prone to LSP violations.

As far as why it is allowed in languages, the justification is basically
that for why C++ even exists. B-) Having the features allows the
developer more direct control over the solution, albeit at the price of
substantially increased fragility.

[Note that the OOPLs have gotten other things not quite right as well
historically, such as directly mapping knowledge responsibilities for
memory storage types.]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
***@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH