home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3363 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
  2. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  3. Newsgroups: comp.object
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <1992Sep1.220559.10346@m.cs.uiuc.edu>
  6. Date: 1 Sep 92 22:05:59 GMT
  7. References: <715276480.1.p00058@mail.psi.net>
  8. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  9. Lines: 47
  10.  
  11. After examining an example of Rumbaugh's,
  12. "Ronald C. Schultz" <p00058@mail.psi.net> writes:
  13.  
  14. >This class specification screams of unnecessary object coupling.  Why, 
  15. >for instance, should a circle need to be aware of the existence of 
  16. >lines? or of the existence of windows?  To me, this class violates the 
  17. >very concept of a circle as defined in any geometry text.    
  18.  
  19. >My question - can someone please explain to me why they feel this class 
  20. >is legitimate, (or illegitimate for that matter).  Why isn't the draw 
  21. >operation and intersectLine operation more appropriately assigned to the 
  22. >drawing application itself, rather than the circle?  
  23.  
  24. I would be happy to.  The class looks fine to me.  I can see where you
  25. are coming from, since I have argued with Ed Berard on this point a
  26. lot.  Basically, I think your assumption that a Circle shouldn't know
  27. anything about a Line is mistaken.  You wouldn't want to make Circle
  28. independent of Point, would you?  If you want to be able to intersect
  29. geometric figures, and I claim that is *essential* to the meaning of
  30. geometric figures, then you have to be able to compare one with another.
  31. This means that you have to have something like intersectLine.
  32.  
  33. I claim that you don't want to make a Circle class that is an independent
  34. standalone entity.  The problem with small classes is that it takes too
  35. much work to reuse them.  There is much bigger payoff when classes come
  36. in families of similar classes, because then you can learn one class and
  37. then just reuse your knowledge for all the other classes.  A Circle should
  38. be part of a GeometricObject family of classes.  There will be a standard
  39. set of operations that all the classes must implement, such as intersecting
  40. with a point or another GeometricObject.  These classes will be designed
  41. as a family and will probably be used as a family.  You are unlikely to use
  42. a Circle in an application and not use a Line.  
  43.  
  44. Draw is definitely more debatable.  My guess is that if you ask a Circle
  45. to draw on a window, it just performs the DrawCircle operation on the
  46. window, which isn't all that bad.  But in general, different applications
  47. will want to draw on different things, and will want to interpret drawing
  48. differently.  Is color needed? Line-width?  Neither of these are attributes
  49. of Circles, so it seems unreasonable to make Circles be responsible for
  50. drawing.
  51.  
  52. In Smalltalk, there is a separation between geometric objects and
  53. graphical objects.  A circle is not displayable.  Instead, you have
  54. to put a wrapper on it that includes color and line width information,
  55. as well as the display operations.
  56.  
  57. Ralph Johnson -- University of Illinois at Urbana-Champaign
  58.