From: 
Newsgroups: comp.lang.c++
Subject: OOD and Inheritance question
Date: 21 Aug 92 17:28:58 GMT
Organization: Chevron Oil Field Research Company

There is _alot_ of opinion coming up. Use "IMHO"s liberally while reading.

hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
...
> Let's say I have a class called Card (A playing card).
> A collection of Cards is a CardPile. So this implies maybe a linked list.

ok, so far. A Set might be a better way of looking at it a CardPile, however.
I tend not to think in terms of linked-lists anymore, especially at the design
phase. It may ultimately be how a Set is implemented, but it is usually the
wrong level of abstraction to think of the problem.

> Question 1: How should CardPile have the link installed: inherited or member
> data? A link is not a Card so maybe it should be a data member. On the other
> hand, I can create a new entity of CardPile by inheriting from both
> Card and Link. (similar to inheriting from class Boy and class Scout to
> make a new class BoyScout.) 

bzzzzt! Whenever you think about inheritance, ask yourself if the subclass is
a 'kind-of' the superclass. In this case, is a CardPile really a kind of Card?
Does a CardPile have the same behaviors as a Card. Of course not. Well, not
many, if any. I may _contain_ Card objects, but it is not a Card itself.

>                             What would be best or does it depend a lot of 
> how I'm going to use CardPile? 

Whenever somebody asks Grady Booch a question like 'What would be the best solution',
he usually responds 'It depends'. In this case, however, there should be no
inheritance relationship between Card and CardPile.

> Question 2: I might want to add member functions that draw the card to make
> a new class of CardView. Should this inherit from Card or CardPile. Or should
> CardPile inherit from CardView which inherits from Card?

We've already removed CardPile from inheritance, so the question here is "Should
there be an inheritance relationship between CardView and Card?". IMNSHO, probably
not. A view or graphical representation of an object (or piece of data) is not
the data. If you make the view class a subclass of the object to be viewed,
then you are restricted to having only one view of that object at any given
time. This is ok in some situtations, but you normally need more flexibility.
(Is my Smalltalk showing?). Also, ask yourself, Is a CardView a kind-of a Card?
This seems to be a little more difficult to answer than the CardPile question.
I wouldn't subclass here.

>     A                              B
> class Card                     class Card
> class CardPile : Card      or  class CardView Card
> class CardView : CardPile      class CardPile : CardView

> In A, I can have a pile of cards or a visible pile of cards. But the drawing
> functionality for drawing a card should probably not be inheriter from CardPile,
> but should be inherited as in B. But in B, I can't just have a pile of card
> without visibility functions. It seems that this would be a good place for
> templates:

> class Card
> class CardView
> class CardPile <T>

My first cut would be something like:

class Card { 
// ...stuff
};

class CardView { 
private:
   Card *card_;
public:
   void display(void);
// ...stuff
};

class CardPile { 
private:
   Set<Card> cards_;
   Set<CardView> cardViews_;
public:
   void display(void); // this would call CardView::display() for each card
// ...stuff
};

// or maybe create a CardPileView class and move the display() behavior
// there, with the cardViews_ attribute.


This is one way of doing it. Even for a little example like this, there are
many many issues that have not been addressed. Some are design issues, some
are language issues. So, don't bother flaming unless you're prepared to
address all of them. A discussion, on the other hand, would be greatly
appreciated.

> I seem to have just answered my own question here. But anyother opinions?

I _always_ have an opinion.

> Bill Volz


Ross Huitt
bytor@ctt.bellcore.com
Newsgroups: comp.lang.c++