Coupling and cohesion
From CSSEMediaWiki
(Difference between revisions)
(→See Also) |
JaninaVoigt (Talk | contribs) |
||
| Line 6: | Line 6: | ||
The fewer and simpler the connections between modules, the easier it is to understand each module without reference to other modules. Minimizing connections between modules also minimizes the paths along which changes and errors can propagate into other parts of the system, thus eliminating disastrous "ripple" effects, where changes in one part cause errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc. | The fewer and simpler the connections between modules, the easier it is to understand each module without reference to other modules. Minimizing connections between modules also minimizes the paths along which changes and errors can propagate into other parts of the system, thus eliminating disastrous "ripple" effects, where changes in one part cause errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc. | ||
</blockquote> | </blockquote> | ||
| + | |||
| + | ===Types of Coupling=== | ||
| + | |||
| + | There are eight different types of coupling, ranging in severity from low to high (from {{Ref|3}}: | ||
| + | |||
| + | *No coupling: Two modules do not communicate with each other and are not dependent on each other in any way. | ||
| + | *Message coupling: Two modules communicate only through a public interface by sending parameterless messages or events but are not dependent on each other in any way. This is the loosest from of coupling. | ||
| + | *Data coupling: Two modules share primitive data, for example through parameters. | ||
| + | *Stamp coupling (or data-structured coupling): Two modules share a composite data structure and each only use a part of that data structure (such as a field in a record). | ||
| + | *Control coupling: One module controls the logic of another module by passing it information of what to do. | ||
| + | *External coupling: Two modules share an externally defined data format, communication protocol or device interface. Both modules will thus be affected by changes to this format or protocol. | ||
| + | *Common coupling: Two modules share the same global data and are thus both affected when changes are made to the data. | ||
| + | *Content coupling: One module modifies or relies on the internal workings of the other module, meaning that changes to the latter module will cause changes to the dependent module. This is the tightest form of coupling and should always be avoided! | ||
==Cohesion== | ==Cohesion== | ||
| Line 18: | Line 31: | ||
#{{Note|1}}W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974. | #{{Note|1}}W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974. | ||
#{{Note|2}} http://javaboutique.internet.com/tutorials/coupcoh/ | #{{Note|2}} http://javaboutique.internet.com/tutorials/coupcoh/ | ||
| + | #{{Note|3}} http://en.wikipedia.org/wiki/Coupling_(computer_science) | ||
==External Links== | ==External Links== | ||
*Read {{Ref|1}} at [http://www.research.ibm.com/journal/sj/132/ibmsj1302C.pdf IBM Research] | *Read {{Ref|1}} at [http://www.research.ibm.com/journal/sj/132/ibmsj1302C.pdf IBM Research] | ||
==See Also== | ==See Also== | ||
*[[Stable dependencies principle]] | *[[Stable dependencies principle]] | ||
Revision as of 03:45, 17 July 2009
First described in [1], coupling and cohesion refers to structuring a set of "highly cohesive classes and to maintain loose coupling between those classes. High-cohesion means well-structured classes and loose coupling means more flexible, extensible software" [2]
Contents |
Coupling
From [1]:
The fewer and simpler the connections between modules, the easier it is to understand each module without reference to other modules. Minimizing connections between modules also minimizes the paths along which changes and errors can propagate into other parts of the system, thus eliminating disastrous "ripple" effects, where changes in one part cause errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc.
Types of Coupling
There are eight different types of coupling, ranging in severity from low to high (from [3]:
- No coupling: Two modules do not communicate with each other and are not dependent on each other in any way.
- Message coupling: Two modules communicate only through a public interface by sending parameterless messages or events but are not dependent on each other in any way. This is the loosest from of coupling.
- Data coupling: Two modules share primitive data, for example through parameters.
- Stamp coupling (or data-structured coupling): Two modules share a composite data structure and each only use a part of that data structure (such as a field in a record).
- Control coupling: One module controls the logic of another module by passing it information of what to do.
- External coupling: Two modules share an externally defined data format, communication protocol or device interface. Both modules will thus be affected by changes to this format or protocol.
- Common coupling: Two modules share the same global data and are thus both affected when changes are made to the data.
- Content coupling: One module modifies or relies on the internal workings of the other module, meaning that changes to the latter module will cause changes to the dependent module. This is the tightest form of coupling and should always be avoided!
Cohesion
From [1]:
Coupling is reduced when the relationships among elements not in the same module are minimized. There are two ways of achieving this - minimizing the relationships among modules and maximizing relationships among elements in the same module. In practice, both ways are used.
The second method is [in effect, increasing cohesion between elements]. "Element" in this sense means any form of a "piece" of the module, such as a statement, a segment, or a "subfunction". Binding is the measure of cohesiveness of a module. The objective here is to reduce coupling by striving for high binding.
References
- ^W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
- ^ http://javaboutique.internet.com/tutorials/coupcoh/
- ^ http://en.wikipedia.org/wiki/Coupling_(computer_science)
External Links
- Read [1] at IBM Research
