home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3409 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.9 KB

  1. Path: sparky!uunet!igor!thor!rmartin
  2. From: rmartin@thor.Rational.COM (Bob Martin)
  3. Newsgroups: comp.object
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <rmartin.715530379@thor>
  6. Date: 3 Sep 92 14:26:19 GMT
  7. References: <715276480.1.p00058@mail.psi.net>
  8. Sender: news@Rational.COM
  9. Lines: 52
  10.  
  11. p00058@mail.psi.net (Ronald C. Schultz) writes:
  12.  
  13. |Object Coupling - In order to better support reuse, objects should be as 
  14. |decoupled as possible from any specific application, so that they may be 
  15. |reused in as many applications as possible.  In Rumbaugh's OMT text he 
  16. |provides a class specification for a circle on page 290.  I quote:
  17.  
  18. [ circle spec deleted ]
  19.  
  20. |This class specification screams of unnecessary object coupling.  Why, 
  21. |for instance, should a circle need to be aware of the existence of 
  22. |lines? or of the existence of windows?  To me, this class violates the 
  23. |very concept of a circle as defined in any geometry text.    
  24.  
  25. |My question - can someone please explain to me why they feel this class 
  26. |is legitimate, (or illegitimate for that matter).  Why isn't the draw 
  27. |operation and intersectLine operation more appropriately assigned to the 
  28. |drawing application itself, rather than the circle?  Rumbaugh's OMT as 
  29. |well as some other OO methods seem to directly oppose long-term reuse of 
  30. |the method's analysis and design products.  Are others encountering the 
  31. |same issues?
  32.  
  33. I agree with you, the example is unecessarily coupled.  Circles, in
  34. general, should not know about windows, and probably not about lines.
  35.  
  36. In order to create a Circle that knows how to draw itself in a window,
  37. you could multiply inherit from both Circle and WindowObject.
  38. WindowObject has a 'draw' method, which is implemented, in the derived
  39. class, to draw the circle.
  40.  
  41. As for methodologies, I use a variation of the Booch method.  I group
  42. my classes into logically cohesive units which Booch calls
  43. "Categories".  Then I measure the number of class relationships within
  44. the category, and call that "Cohesion".  The number of class
  45. relationships which extend outside the category I call "Coupling".
  46. Dividing both by the number of classes in the category gives me
  47. normalized values which can be used to compare one category to
  48. another.  Finally, the ration of these two numbers (Cohesion/Coupling)
  49. is a metric  which I call "Health"  The bigger this number, the more
  50. cohesive and less coupled the category is.
  51.  
  52. Thus, I don't measure the coupling and cohesion of classes directly.
  53. I measure the coupling and cohesion of categories.  This makes more
  54. sense to me since most applicatoins are assemblages of many, highly
  55. collaborative groups of classes.
  56.  
  57.  
  58. --
  59. Robert Martin                        Training courses offered in:
  60. R. C. M. Consulting                       Object Oriented Analysis
  61. 2080 Cranbrook Rd.                        Object Oriented Design
  62. Green Oaks, Il 60048 (708) 918-1004       C++
  63.