Coupling and cohesion

Latest revision as of 03:21, 25 November 2010

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] Therefore, we should always aim for low coupling and high cohesion.

Coupling

Coupling refers to the degree of direct knowledge that one class has of another.

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.

Strong coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior. Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes. Loose coupling provides extensibility to your design. You can easily add a new concrete class later that implements that same interface without ever having to modify and recompile the dependent class. User:Paul Williams

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!

Measuring Coupling with Software Metrics Tools

Many forms of coupling can be measured using Software Metrics Measuring Tools. For example, CBO (Coupling between Objects) is a known metric used to measure number of classes that a particular class is coupled to. Other metrics that relate to coupling between classes include:

• RFC: Response for Class
• CE: Efferent Coupling
• CA: Afferent Coupling
• CF: Coupling Factor

Definitions for those metrics can be found here:12

Metrics tools vary in supporting those metrics, some even adopt different definitions of those metrics. Here is a list of some interesting metrics tools:

• STAN
• SourceMonitor
• Eclipse Metrics Plugin
• many more here

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.

Types of Cohesion

There are seven different types of cohesion, ranging from low to high (from [4]):

• Coincidental cohesion: Parts are grouped into modules arbitrarily and there is no significant relationship between parts of a module. This is the lowest form of cohesion.
• Logical cohesion: Parts are grouped into a module because they logically do similar things even if they are very different from each other. A module that contains all IO methods is an example of this type of cohesion.
• Temporal cohesion: Parts of a program are grouped by when they are processed so that one module contains all parts of a program that are used at one particular time of execution.
• Procedural cohesion: Parts are grouped into a module because they all execute a similar sequence of actions.
• Communicational cohesion: Parts are grouped into a module because they operate on the same data.
• Sequential cohesion: Parts are grouped into a module because they follow a sequence in that the output from one part forms the input to another part.
• Functional cohesion: Parts are grouped into a module because they all contribute to a single task. This is the highest form of cohesion and is what we would ideally like all our modules to exhibit.

Metrics for Measuring Cohesion

Just like Coupling, Cohesion can also be measured using software metrics tools. Here is a useful link discussing some cohesion metrics.

Related concepts and heuristics

Keep related data and behaviour in one place

Riel's heuristic Keep related data and behavior in one place tends to produce highly cohesive modules where the data and behaviour that acts on the data are close to each other. If this principle is not followed, modules will be more tightly coupled than they need to be. If we separate data and behaviour that conceptually belongs together into separate modules, those modules will be very closely linked and will need to communicate heavily with each other, leading to tight coupling.

References

1. ^W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.
2. ^ http://javaboutique.internet.com/tutorials/coupcoh/
3. ^ http://en.wikipedia.org/wiki/Coupling_(computer_science)
4. ^ http://en.wikipedia.org/wiki/Cohesion_(computer_science)

External Links

• Read [1] at IBM Research

See Also

• Stable dependencies principle