advice on programming style: is multiple inheritance bad?

Gary Stephenson garys at ihug.com.au
Mon Feb 2 03:06:49 EST 2004


Fwiw, I am both a human, and a customer of my bank.  My computer is both an
"electrical_device" and a "depreciable-asset".  It is completely natural in
the real world for objects to have multiple "is-a" relationships with
various other objects.   Why then, should we not use multiple inheritance
when modelling such relationships?

One major reason why multiple inheritance has such a bad name can be sheeted
back to the brain-dead way in which C++ implements it.  The other main
reason is that inheritance itself, single or multiple, implementation or
interface, is _way_ overrated as a code structuring technique.  This is
probably due to it not even being consistently defined - it seems to mean
different things to different people at different times (depending on which
language they're currently working with).

IMHO, inheritance only works robustly in the face of change if you can
guarantee that the potential instances of your (sub)classes form a strict
proper subset (mathematically speaking) of the potential instances of their
ancestor classes.  afaik, which is not terribly far really
;-) , there is no OO language on earth that can _guarantee_ this subclass ==
subset relationship for you - you have to arrange it yourself (somehow).

Other folk have also suggested that in order to properly achieve the above,
you need to follow the rule: "only abstract classes can be subclassed".
That is, if you want to create class B as a subclass of class A, and A is
not already an abstract class, you should create a third class A', which
_is_ an abstract class, and have both class A and class B inherit from that.
For a far better explanation of this and many other related issues I refer
the interested reader to:

     http://okmij.org/ftp/Computation/Subtyping/Trouble.html

my $A0.0148,

gary


"Uwe Mayer" <merkosh at hadiko.de> wrote in message
news:bvjhkv$ss4$1 at news.rz.uni-karlsruhe.de...
> Hi,
>
> I got a class A2 that needs to inherit from class A1.
> A2, as well as some other classes implement a same functionality and in
> order to prevent code duplication I'd like to factorize that (potentially)
> duplicate code into a class SuperA from which then A2 and all other
classes
> could inherrit.
> However, this would cause A2 to have two super classes A1 and SuperA -
which
> is possible of course in Python.
>
> My question is: is that bad programming style?
> From C++ and Java we "learn" that you shouldn't do that.
>
> Class A is automatically generated from other tools, so I can't solve the
> problem by just letting A1 inherit from SuperA.
>
> Your opinions?
>
> Ciao
> Uwe
> -- 
>





More information about the Python-list mailing list