home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12736 < prev    next >
Encoding:
Text File  |  1992-08-21  |  4.5 KB  |  125 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!walter!grumpy!bytor
  3. From: bytor@grumpy.bellcore.com (Ross Huitt)
  4. Subject: Re: OOD and Inheritance question
  5. Message-ID: <1992Aug21.191816.9791@walter.bellcore.com>
  6. Sender: bytor@grumpy (Ross Huitt)
  7. Nntp-Posting-Host: grumpy.ctt.bellcore.com
  8. Organization: Bellcore
  9. References:  <6298@lhdsy1.lahabra.chevron.com>
  10. Date: Fri, 21 Aug 92 19:18:16 GMT
  11. Lines: 112
  12.  
  13. Article: 29649 of comp.lang.c++
  14. Path: walter!uunet!lhdsy1!kato.lahabra.chevron.com!hwrvo
  15. From: 
  16. Newsgroups: comp.lang.c++
  17. Subject: OOD and Inheritance question
  18. Message-ID: <6298@lhdsy1.lahabra.chevron.com>
  19. Date: 21 Aug 92 17:28:58 GMT
  20. Sender: news@lhdsy1.lahabra.chevron.com
  21. Organization: Chevron Oil Field Research Company
  22. Lines: 42
  23.  
  24. There is _alot_ of opinion coming up. Use "IMHO"s liberally while reading.
  25.  
  26. hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
  27. ...
  28. > Let's say I have a class called Card (A playing card).
  29. > A collection of Cards is a CardPile. So this implies maybe a linked list.
  30.  
  31. ok, so far. A Set might be a better way of looking at it a CardPile, however.
  32. I tend not to think in terms of linked-lists anymore, especially at the design
  33. phase. It may ultimately be how a Set is implemented, but it is usually the
  34. wrong level of abstraction to think of the problem.
  35.  
  36. > Question 1: How should CardPile have the link installed: inherited or member
  37. > data? A link is not a Card so maybe it should be a data member. On the other
  38. > hand, I can create a new entity of CardPile by inheriting from both
  39. > Card and Link. (similar to inheriting from class Boy and class Scout to
  40. > make a new class BoyScout.) 
  41.  
  42. bzzzzt! Whenever you think about inheritance, ask yourself if the subclass is
  43. a 'kind-of' the superclass. In this case, is a CardPile really a kind of Card?
  44. Does a CardPile have the same behaviors as a Card. Of course not. Well, not
  45. many, if any. I may _contain_ Card objects, but it is not a Card itself.
  46.  
  47. >                             What would be best or does it depend a lot of 
  48. > how I'm going to use CardPile? 
  49.  
  50. Whenever somebody asks Grady Booch a question like 'What would be the best solution',
  51. he usually responds 'It depends'. In this case, however, there should be no
  52. inheritance relationship between Card and CardPile.
  53.  
  54. > Question 2: I might want to add member functions that draw the card to make
  55. > a new class of CardView. Should this inherit from Card or CardPile. Or should
  56. > CardPile inherit from CardView which inherits from Card?
  57.  
  58. We've already removed CardPile from inheritance, so the question here is "Should
  59. there be an inheritance relationship between CardView and Card?". IMNSHO, probably
  60. not. A view or graphical representation of an object (or piece of data) is not
  61. the data. If you make the view class a subclass of the object to be viewed,
  62. then you are restricted to having only one view of that object at any given
  63. time. This is ok in some situtations, but you normally need more flexibility.
  64. (Is my Smalltalk showing?). Also, ask yourself, Is a CardView a kind-of a Card?
  65. This seems to be a little more difficult to answer than the CardPile question.
  66. I wouldn't subclass here.
  67.  
  68. >     A                              B
  69. > class Card                     class Card
  70. > class CardPile : Card      or  class CardView Card
  71. > class CardView : CardPile      class CardPile : CardView
  72.  
  73. > In A, I can have a pile of cards or a visible pile of cards. But the drawing
  74. > functionality for drawing a card should probably not be inheriter from CardPile,
  75. > but should be inherited as in B. But in B, I can't just have a pile of card
  76. > without visibility functions. It seems that this would be a good place for
  77. > templates:
  78.  
  79. > class Card
  80. > class CardView
  81. > class CardPile <T>
  82.  
  83. My first cut would be something like:
  84.  
  85. class Card { 
  86. // ...stuff
  87. };
  88.  
  89. class CardView { 
  90. private:
  91.    Card *card_;
  92. public:
  93.    void display(void);
  94. // ...stuff
  95. };
  96.  
  97. class CardPile { 
  98. private:
  99.    Set<Card> cards_;
  100.    Set<CardView> cardViews_;
  101. public:
  102.    void display(void); // this would call CardView::display() for each card
  103. // ...stuff
  104. };
  105.  
  106. // or maybe create a CardPileView class and move the display() behavior
  107. // there, with the cardViews_ attribute.
  108.  
  109.  
  110. This is one way of doing it. Even for a little example like this, there are
  111. many many issues that have not been addressed. Some are design issues, some
  112. are language issues. So, don't bother flaming unless you're prepared to
  113. address all of them. A discussion, on the other hand, would be greatly
  114. appreciated.
  115.  
  116. > I seem to have just answered my own question here. But anyother opinions?
  117.  
  118. I _always_ have an opinion.
  119.  
  120. > Bill Volz
  121.  
  122.  
  123. Ross Huitt
  124. bytor@ctt.bellcore.com
  125.