CSC/ECE 517 Fall 2007/wiki2 7 an: Difference between revisions
| Line 46: | Line 46: | ||
=== Common coupling === | === Common coupling === | ||
=== Control coupling === | === Control coupling === | ||
As the name suggests, one module can control the decisions made by another module. This is usually done by passing the controlling information from one module to another. An example would be a module that prints a name in either upper or lower case, the decision of which is taken by another module which passes a control flag (0 or 1) to the first module. For this type of coupling to work efficiently, one module must know the internal logic and structure of another module. Coupling between modules d and e represents this type of coupling. | |||
=== Stamp coupling === | === Stamp coupling === | ||
=== Data coupling === | === Data coupling === | ||
Revision as of 01:47, 24 October 2007
Cohesion and coupling. Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is challenging to find good examples that are succinct. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling. Be sure to mention the metrics that can be used to measure how well a program conforms to the principles of high cohesion and low coupling.
What is coupling?
Coupling is the degree to which each program module relies on each one of the other modules. Unnecessary object coupling needlessly decreases the reusability of the coupled objects and also increases the chances of system corruption when changes are made to one or more of the coupled objects.
Thus the design goal is to minimize coupling and improve reusability. Coupling is broadly divided into two types-low coupling and high coupling. Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability.
On the other hand, systems with high coupling face the following problems
• Change in one module forces a ripple of changes in other modules.
• Modules are difficult to understand in isolation.
• Modules are difficult to reuse or test because dependent modules must be included.
Thus it is evident that low coupling tends to produce reusable methods. But it is also not possible to write completely decoupled methods since the program will not work.
Examples of coupling
High coupling
A perfect example of high coupling is the human body. Every organ can be considered as an independent module which is intricately dependent on many other organs for its functioning. An irregularity in the working or performance of any organ affects almost the entire body. Thus the modules can be considered to be tightly coupled in this case. A direct consequence of this high coupling is that reuse of modules is extremely difficult. Imagine doing a liver transplant without having to worry about organ rejection!!! This is unfortunately not possible due to the highly coupled nature of the human body.
Low coupling
An example of a low coupled system is the modern plumbing system. Almost every part of the system can be replaced with ease since the modules hardly depend on each other.
Types of coupling
Content coupling
In this type of coupling, one module modifies or relies on the working of another module. Therefore any change in the second module leads to a change in the working of the dependent module. An example of this type of coupling would be case in which one module refers to some data in another module by a fixed offset. Thus as the data in the module changes the value accessed by the dependent module also changes.
Content coupling is bad and should be avoided. The reasons are
• Changes in the called module may require corresponding changes in the calling module too.
• Since the two modules are inextricably linked, it is not possible too reuse the calling module without including the called module.
Common coupling
Control coupling
As the name suggests, one module can control the decisions made by another module. This is usually done by passing the controlling information from one module to another. An example would be a module that prints a name in either upper or lower case, the decision of which is taken by another module which passes a control flag (0 or 1) to the first module. For this type of coupling to work efficiently, one module must know the internal logic and structure of another module. Coupling between modules d and e represents this type of coupling.