Variable inheritance

[Magnus Lycka]

Roman Suzi wrote:
> Multiple inheritance says it bad design.

I wouldn't say that in general. But most of the
time, and certainly in this case!

The reasonable use of multiple inheritance is
for so-called mixin-classes, that gives some
particular behavior to a class. This can be used
to give classes features such as persistence,
automagic logging of some sort, or various support
for debugging etc.

Basically, inheritance is then used as an
implementation device, and it has nothing to do
with the more abstract _design_ classes. The mixin
does not represent a real world object that would
pop up during requirements capture, analysis or
early design.

Both Printer.PSPrinter and OutputDevice.ToLP and
are obviously real world objects. They can even
be physically touched. (But don't touch the
OutputDevice without a grounding strap. :)

class PSToLP(Printer.PSPrinter, OutputDevice.ToLP)
means that PSToLP IS A Printer.PSPrinter and IS
ALSO A OutputDevice.ToLP. As an electronics engineer,
I can tell you it isn't so.

> Probably, you want a third container class, which
> will hold your Printer and OutputDevice classes
> and provide communication between them.

Right. This is one interpretation. I.e. that a PStoLP
(transfer) USES a Printer and an OutputDevice. Thus
as Roman suggests, Printer and OutputDevice are not
base classes, but attributes. USES, not IS-A.

The other possible interpretation is that you have a
PSToLP (device), or rather GraphicLanguageToLP (device),
which IS A special kind of OutputDevice.ToLP, i.e. a
subclass of OutputDevice.ToLP.

Roman is probably right. I think you want the first
option. If you want the second, you have to consider
if they really have this so much in common as to say
that they are the same class, only one more specialized.
Do you want programmers to be able to treat a
GraphicLanguageToLP just as if it was an
OutputDevice.ToLP? Would that be meaningful in your
design? And do you really see GraphicLanguageToLP
as a kind of OutputDevice? If the answer is no,
choose Roman's suggestion.

Try  not to abuse or contort inheritance or the other
OO features of a programming language. Its strength
lies in its ability to raise the level of abstraction
and to map the real world in a better way.

Making your code look more like the real world makes
the program easier to understand, and to modify when
the real world changes.

> On Mon, 21 May 2001, Clarence Gardner wrote:
> >class PSToLP(Printer.PSPrinter, OutputDevice.ToLP):
...
> >Now I want to make two similar classes like this:
> >    PSToLP = GraphicLanguageToLP(Printer.PSPrinter)
> >    PCLToLP = GraphicLanguageToLP(Printer.PCLPrinter)

/Magnus

-- 
Magnus Lyckå | Älvans väg 99 | magnus at thinkware.se | tel: 070-582 80 65
Thinkware AB | 907 50  UMEÅ  | www.thinkware.se    | fax: 070-612 80 65