[Tutor] subclassing across multiple modules
Brian van den Broek
bvande at po-box.mcgill.ca
Fri Mar 18 16:28:55 CET 2005
Kent Johnson said unto the world upon 2005-03-18 07:35:
> Brian van den Broek wrote:
>> Kent Johnson said unto the world upon 2005-03-17 20:44:
>>> The multiple inheritance from MyNode and Toolkit.NodeX is a smell. I
>>> guess you do this because you want to override methods of
>>> Toolkit.Node as well as Toolkit.NodeX, or add methods to both MyNode1
>>> and MyNode2? I would look for another way to do this, maybe using
>>> some kind of helper class to hold some common functions?
<SNIP Brian's original rational for using multiple inheritance>
>> Are you suggesting the multiple inheritance is always a smell?
> No. Some people would agree with that - e.g. the creators of Java - but
> I have seen many times where
> MI is useful. Usually it is to combine a primary base class with a mixin
> - a class that adds
> functionality orthogonal to that of the base class, or that modifies a
> carefully chosen set of base
> class methods.
<SNIP GUI example>
> BUT there are some clear gotchas to MI. They mostly arise when you
> inherit from classes that
> themselves have a common base class. The "diamond" pattern is the usual
> class A:
> class B(A):
> class C(A):
> class D(B, C):
> Now you can have all kinds of fun (i.e. subtle bugs and confusion) if A,
> B, C and D have methods in
> common and if they want to call the methods of their base classes. One
> of the changes is new-style
> classes (the addition of super() and a change to the "method resolution
> order") was made to address
> some deficiencies in how old-style classes handle this situation.
> So, calling this a code smell is probably not the right term. It's more
> like a red warning light and
> klaxon :-) You just don't want to do this without understanding the issues.
> and PEP
> 253 for details or google "diamond multiple inheritance"
Well, if I let failure of understanding stop me, I'd still be writing
nothing but DOS batch files :-) But, point taken.
Thanks for the links. I'd read about the diamond pattern in the past,
but at a time before I'd ever written a class to call my own. Pushed
by this discussion, and with a problem context to read the texts
through, I re-read the dead-tree sources I have at hand. For anyone
following along, the relevant section of the Nutshell (p 88ff) makes a
good deal of sense of this. Learning Python 370ff is also on point.
>> I'll google, but my only grasp of the meaning of "helper class" is
>> what comes from intuition.
> For example, instead of subclassing Toolkit.Node, could you define the
> extra methods in another
> class. Then your NodeX subclasses can inherit from Toolkit.NodeX and
> NodeHelper. e.g.
> class MyNodeHelper:
> def doSomethingSpecial(self):
> # does something with a Toolkit.Node
> class MyNode1(Toolkit.Node1, MyNodeHelper):
> This is an example of a mixin class.
OK, that makes sense. The effect, as I understand it, is to put the
new behaviour common to NodeX classes in a separate bundle for safety,
thereby making the MRO more transparent. And, as I learned when I used
to work road construction, safety first! :-)
Thanks for the help, Kent.
Best to all,
More information about the Tutor