wellington
Member
Registered: Jun 2001
Location:
Posts: 37 |
This is a good question but hard to answer.
Generally speaking you want low-coupling and high-cohesion, as explained very nicely in Craig Larman's book, Applying UML and Patterns.
Using the calculator example from this forum, I will try to provide an example of low-coupling. Low-coupling means simply that only a few key classes know about eachother. In other words, classes only know what they have to know. The benefit of low-coupling is ease of maintenance. If there are changes to the interface for a class, relatively little impact is made on surrounding classes.
In the Object-Oriented Calculator, the model and view classes are separated into different packages by the same names. You can see the separation in the Calculator class diagram where the top half shows classes in the view and the bottom half shows classes in the model.
The only real coupling here is between the Calculator and the Cpu classes. Two methods on Cpu provide the main interface, enterOperation() and enterDigit(). This low coupling makes it very easy to provide different views and also to provide a testing framework. Everything from Cpu and below is a black-box; the view doesn't need to know anything about other classes in the model.
To see this low-coupling in the code, click on the Calculator class on the diagram and the source code will display in another window. You will see that only one class is imported from the model and that is Cpu. Calculator doesn't know about any other classes in the model.
Hope this helps for low-coupling. I will think of a good example for high-cohesion.
Report this post to a moderator | IP: Logged
|