CSC/ECE 517 Summer 2008/wiki3 3 n1: Difference between revisions
Line 23: | Line 23: | ||
==Type of Coupling== | ==Type of Coupling== | ||
Coupling exists in various forms and degrees. This section describes the types of coupling commonly found, and how to avoid or reduce | Coupling exists in various forms and degrees. This section describes the types of coupling commonly found in modern object-oriented system, and how to avoid or reduce them. | ||
===Content coupling=== | ===Content coupling=== |
Revision as of 02:33, 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 modularize due high 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 outweighed 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 (interface) rather than the narrowest type.
- Code to interfaces, not classes. Wherever possible write 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 passed 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.
Type of Coupling
Coupling exists in various forms and degrees. This section describes the types of coupling commonly found in modern object-oriented system, and how to avoid or reduce them.
Content coupling
Content coupling is a high coupling. It exists between two classes when one class uses the variables of another class directly. When the format of the content changes, i.e. variable name changes, the other class using the content need to be modified. This form of coupling is undesirable because the internal implementation of a class is exposed to another class. To reduce coupling, private access control should be applied to the variables in the class, and the class should provide public accessor methods, i.e. getters and setters.
Common coupling
Common coupling exists between classes that share a global data. Changing the type of the shared data requires modifications in all the classes using the global data. To reduce common coupling, one class should contain global data and provide public methods to obtain or modify the global data.
External coupling
External coupling exists in classes that uses communication protocol or device interface imposed by third party classes, such as a class using JavaMail classes for emailing. Use facade pattern to encapsulate subsystems and lower coupling.
Data coupling
Data coupling is relatively low coupling that exists when one class passes simple data to another as an argument; this is common. Coupling is due to the meaning of data passed. If the meaning of the data is changed then the other class has to modify to accommodate the change. To reduce data coupling, minimal arguments should be passed between classes - fewer the better. Each argument should contain the widest possible type.
Message coupling
Message coupling is low coupling. Classes are not dependent on each other instead they exchange parameter-less messages. A common exchange message may be written in XML. The message is then interpreted differently based on the need of each class.