Path: utzoo!utgpu!watmath!clyde!att!rutgers!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!dan-hankins
From: dan-hankins@cup.portal.com (Daniel B Hankins)
Newsgroups: comp.lang.misc
Subject: Re: object oriented design decision
Message-ID: <11522@cup.portal.com>
Date: 20 Nov 88 02:38:19 GMT
References: <4086@enea.se>
Organization: The Portal System (TM)
Lines: 61

In article <795@euraiv1.UUCP> reino@euraiv1.UUCP (Reino de Boer) writes:
>How about having two separate classes for a linked list:
>Class List
>Class EmptyList
>and trying to build a stack as subclass of List and EmptyList.  Isn't
>multiple inheritance nicer than trying to make class List act like two
>separate concepts ?

I suggest trying to pick a better example.  It seems to me that if you are
going to have two separate classes for a linked list, you might as well
have two separate classes for a stack.  In this case, those classes would
be Stack and EmptyStack, which would be subclasses of List and EmptyList,
respectively.


In article <578@poseidon.ATT.COM> ech@poseidon.ATT.COM (Edward C Horvath)
writes:
>> Multiple inheritance is an indication that something is wrong with the class
>> hierarchy.  Restructure that and single inheritance should do fine...
>
>I used to think so, too.  Then I read Meyer's book: multiple inheritance
>is a concept with immense power, not a "hack."
>
>I am less convinced of the need for REPEATED inheritance, i.e.  inheriting
>from two or more classes with a common ancestor.  Even here, however,
>notions like nodes which are simultaneously on two types of linked
>lists are well-served by repeated-inheritance-with-renaming.

In article <4086@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>>Multiple inheritance is an indication that something is wrong with the class
>>hierarchy.  Restructure that and single inheritance should do fine.  
> 
>Could anyone elaborate this? I fail to see what is bad with multiple 
>inheritance. If I want to store an object in a tree and a 
>linked list simultaneously, what is wrong with my class structure?

These two sound like the same example.  In either case, is is much better
programming practice to have a class Node which is not tied to any
structure.  Objects which are nodes of class TreeNode or ListNode or
whatever should have objects of class Node as an acquaintance (or variable,
in Smalltalk terminology).


In article <678@quintus.UUCP> pds@quintus.uucp (Peter Schachte) writes:
>A better example is toy truck.  A toy truck IS a toy and it IS a truck,
>so it might make sense to have it inherit from both.  It could inherit
>number-of-wheels from truck, and qualitative-size from toy.  But
>dealing with the conflicts, it seems to me, is nontrivial at best, and
>sometimes a quagmire of hacks.
>
>Does someone have a GOOD theory of multiple inheritance that deals with
>conflicts in more than an ad hoc way?

This is the tricky one.  This is the one that makes me think that perhaps
a tree, or even a digraph, is not the proper way to think about classifying
objects.

What is the proper way?  I'll let you know when and if I figure it out.


Dan Hankins