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