advice on programming style: is multiple inheritance bad?
roy at panix.com
Tue Feb 3 01:47:43 CET 2004
Uwe Mayer <merkosh at hadiko.de> wrote:
> On a lecture on software engeneering I was tought that multiple
> inheritance was a bad thing to do, since there are problems with the
> resolution order which leads to badly readable code, induces errors,
> shows poor software design, etc.
There are certainly problems with multiple inheritance, but that doesn't
mean that all uses of MI are inherently evil. It is certainly
worthwhile to listen to the arguments the anti-MI people make and think
about the problems.
Of course, you need to be able to factor out those arguments which are
language-specific from those which are more general.
> When writing the sentence above I was implying that m.i. in C++ propably is
> difficult to handle
Everything in C++ is difficult to handle. I don't see anything about
C++'s MI implementation which stands out as particularly worse or more
complex than the rest of the class inheritance system.
> How much effort is it worth to keep up good transparent programming design
> at cost of more code, more levels of delegation (slower) and a more complex
> interior in general?
That's a complicated question, and I'm not sure I fully understand what
you're asking, but my general answer would be that your main goal should
be to make the program easy for somebody else to understand (perhaps
years from now, when you're no longer around to answer questions). The
number of lines of code is secondary, and speed of execution even less
When the whole thing is done, and you're sure everything works, that's
the time to figure out if it's fast enough. If it's not, then you
should start profiling things to figure out where most of the time is
being spent and look there for speedups. The biggest speedups will
typically come from algorithmic improvements, not from low-level
optimizations like using or not using MI.
More information about the Python-list