CSC/ECE 517 Summer 2008/wiki3 3 n1: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
 
No edit summary
Line 1: Line 1:
Low coupling. We introduced the idea of low coupling in Lecture 20, and used the Observer pattern as an example in Lecture 23. But we've really only scratched the surface on what there is to know about achieving low coupling. Browse the Web and the ACM DL for other information, both theoretical and practical, and produce a guide to what there is to know about low coupling. Be sure to highlight those aspects that would be appropriate for inclusion in CSC/ECE 517.
==Introductiion==
In object-oriented system, coupling is the degree to which a class relies on other classes.  Low (or loose) coupling means that a class interacts with another class through an interface and does not to be concerned with the other class's internal implementation. In other words, with low coupling, a change in one class will not require a change in the implementation of another class.  Low coupling is desirable; systems with high coupling usually experience the following difficulties:
 
* Classes are difficult to understand when examined in isolation.
* Changing in one class create a ripple effect that requires changes in other classes.
* Codes are harder to modulize to class dependency, thus become less reusable.
 
 
In rare cases, a high coupling is desirable to achieve maximum efficiency and performance, such as codes that perform hardware intensive functions, i.e. batch I/O.  However in general the cost of reduced performance is outweighted by the benefits of reusable components and quicker software development that result from low coupling.
 
==Minimizing coupling==
To avoid the pitfalls of high coupling in a system mentioned earlier, classes should be designed in such a way that there is separation of responsibilities; they should be written in such a way that changing one class is not likely to require change in other classes.  The following guidelines help to minimizing coupling:
 
#Design classes so that variables have the widest possible type rather than the narrowest type.  For instance, in Java the widest possible is an interface that can be implemented by any number of classes.
#Code to interfaces, not classes. Wherever possible write your code so that objects are referred to by the interfaces they implement instead of by the concrete class to which they belong.
#Encapsulate the concepts that vary.
#Divide different responsibilities among different objects.
#Apply Observer pattern when an object must be notified of an action or event performed by another object.
#Apply Mediator pattern where complexity of communications between classes becomes an issue.  Mediator provides a unified interface for a set of interfaces in a sub system, allowing objects to communicate with mediator instead of each other.
#Apply Law of Demeter; a given object should assume as little as possible about the structure or properties of others
#*The less arguments past to a class, the better.
#*Encapsulate chains of routine calls that involve multiple classes into one class.  So a given class only deals with one class instead of many.

Revision as of 02:03, 27 July 2008

Introductiion

In object-oriented system, coupling is the degree to which a class relies on other classes. Low (or loose) coupling means that a class interacts with another class through an interface and does not to be concerned with the other class's internal implementation. In other words, with low coupling, a change in one class will not require a change in the implementation of another class. Low coupling is desirable; systems with high coupling usually experience the following difficulties:

  • Classes are difficult to understand when examined in isolation.
  • Changing in one class create a ripple effect that requires changes in other classes.
  • Codes are harder to modulize to class dependency, thus become less reusable.


In rare cases, a high coupling is desirable to achieve maximum efficiency and performance, such as codes that perform hardware intensive functions, i.e. batch I/O. However in general the cost of reduced performance is outweighted by the benefits of reusable components and quicker software development that result from low coupling.

Minimizing coupling

To avoid the pitfalls of high coupling in a system mentioned earlier, classes should be designed in such a way that there is separation of responsibilities; they should be written in such a way that changing one class is not likely to require change in other classes. The following guidelines help to minimizing coupling:

  1. Design classes so that variables have the widest possible type rather than the narrowest type. For instance, in Java the widest possible is an interface that can be implemented by any number of classes.
  2. Code to interfaces, not classes. Wherever possible write your code so that objects are referred to by the interfaces they implement instead of by the concrete class to which they belong.
  3. Encapsulate the concepts that vary.
  4. Divide different responsibilities among different objects.
  5. Apply Observer pattern when an object must be notified of an action or event performed by another object.
  6. Apply Mediator pattern where complexity of communications between classes becomes an issue. Mediator provides a unified interface for a set of interfaces in a sub system, allowing objects to communicate with mediator instead of each other.
  7. Apply Law of Demeter; a given object should assume as little as possible about the structure or properties of others
    • The less arguments past to a class, the better.
    • Encapsulate chains of routine calls that involve multiple classes into one class. So a given class only deals with one class instead of many.
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki3_3_n1&oldid=15992"