home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12746 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.6 KB
  1. Path: sparky!uunet!igor!dirac!rmartin
  2. From: rmartin@dirac.Rational.COM (Bob Martin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: OOD and Inheritance question
  5. Message-ID: <rmartin.714436548@dirac>
  6. Date: 21 Aug 92 22:35:48 GMT
  7. References: <6298@lhdsy1.lahabra.chevron.com>
  8. Sender: news@Rational.COM
  9. Lines: 50
  10.  
  11. hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
  12.  
  13. |I have a question on how to design a set of classes. It probably has a really
  14. |simple answer. But here goes anyway:
  15.  
  16. |Let's say I have a class called Card (A playing card).
  17. |A collection of Cards is a CardPile. So this implies maybe a linked list.
  18.  
  19. |Question 1: How should CardPile have the link installed: inherited or member
  20. |data? A link is not a Card so maybe it should be a data member. On the other
  21. |hand, I can create a new entity of CardPile by inheriting from both
  22. |Card and Link. (similar to inheriting from class Boy and class Scout to
  23. |make a new class BoyScout.) What would be best or does it depend a lot of 
  24. |how I'm going to use CardPile? 
  25.  
  26. You are diving much too quickly into the details of your
  27. implementation.  First, design your application, then fiddle with the
  28. details of how items get placed into linked lists.
  29.  
  30. The real abstractions here are Card and Pile.  A Card represents a
  31. single playing card.  It has state: (suit and rank).  It's behavior is
  32. unknown to me, but depends upon your application.  For example, for a
  33. poker application, a card will probably need to compare itself with
  34. another card according to the ranking rules of poker.  
  35.  
  36. Piles are groups of cards.  They have state (some number of cards) and
  37. they also have behavior (shuffle, draw from top, draw from bottom,
  38. draw random, cut, etc....)
  39.  
  40. There are no inheritance relationships between these classes.  
  41.  
  42. As to "how the link should be installed"; Card should not have to know
  43. this.  In fact, card should know nothing about Pile at all.  It is up
  44. to Pile to figure out how to manage its list of Card objects.  This
  45. can be done by creating a carrier object which maintains your link,
  46. and also refers to a particular Card.  Pile creates carriers as Cards
  47. are added to the list. 
  48.  
  49. However, I doubt that you should make Pile manage the list directly.
  50. You probably want to create a List class template, and then have Pile
  51. contain a  List < Card >; member variable....  This helps to decouple
  52. the Pile from the kind of list being used so keep the Cards....
  53.  
  54.  
  55.  
  56. --
  57. Robert Martin                        Training courses offered in:
  58. R. C. M. Consulting                       Object Oriented Analysis
  59. 2080 Cranbrook Rd.                        Object Oriented Design
  60. Green Oaks, Il 60048 (708) 918-1004       C++
  61.