Unintended inheritance

[Alex Martelli]

Kay Schluehr <kay.schluehr at gmx.net> wrote:
   ...
> To prevent unintended inheritance C# introduced a relatively complex
> contract semantics using three modifiers virtual, override and new. Is
> this issue serious for Python programmers, in particular for those
> working in larger projects ( Twisted, Zope ... ) or is it not? If not,
> why not?

I have not found it to be a particular problem (in C++ as well as in
Python or Java), because subclasses' coupling to superclasses is too
strong anyway to expect everything to just work smoothly when the
superclass's interface is changed, and even the most semidecent of
unittests easily catch this specific problem -- obviously all subclasses
must be recompiled and tested when a superclass's interface is changed
in any way. Other kinds of coupling are subtler and more problematic
(not so much in Python as in C++, I'd say, but it's arguable).

Lakos' book on large-scale design for C++ has good advice on dependency
control, which boils down to (WAY oversimplifying): each component must
expose to all others only unchanging abstract interfaces; anything
depending on anything beyond an abstract interface (as a subclass must)
must be in the same component as what it depends on.  Inheritance, while
way handy, introduces too-strong coupling (==dependencies) to be freely
used across independently developed and maintained components; and any
change in interface (I would argue, in fact, most any change in
PROTOCOL, which is a stronger constraint) must occur on new, separate
interfaces (which may well extend the existing ones, of course).

Yes, frameworks (separately developed, large components which are
*supposed* to be used via inheritance by separately developed and
maintained components) are quite problematic in terms of Lakos' rules
and guidelines (if you're at all interested in these subjects you should
surely read Lakos' book, anyway: no summary can do it justice). But I
believe (with no real-world experience of C#, admittedly) that they will
remain essentially just as problematic with C#'s complex rules -- a new
release of a framework, which changes protocols, will still be able to
break uncountable independently developed and maintained smaller
components, and the fact that the compiler catches the breakage (if, of
course, the other components DO get recompiled) rather than relying on
semidecent unittests is scant consolation -- there's still no bound to
the amount of work that may be needed to repair the wreckage.


Alex