Saturday, September 24th, 2016
In Software Engineering, Cohesion is often contrasted with Coupling. These are the two prevailing factors that determine how well a software product can adapt, improve, and be extended without imploding in on itself. They are two different concepts:
Cohesion of a single module/component is the degree to which its responsibilities form a meaninful unit. Higher cohesion is better.
A component exhibits high cohesion when all its functions/methods are strongly related in terms of function. Cohesion describes how “focused” a piece of software is. It is very related to the “Single Responsibility Principle“.
- High cohesion requires that the module be, in a sense, single-minded. A class may have high cohesion if all of its methods are closely related.
- Low cohesion means that a module attempts to accomplish too many tasks, or relates to multiple distinct sets of data.
Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability.
Coupling between modules/components is their degree of mutual interdependence. Lower coupling is better.
- High coupling means that two componentes are too interrelated, which can make maintaining the system very difficult.
- Low coupling means that changes in one component never or rarely necessitate a change in the other.
Coupling or dependency is the degree to which each program module relies on each one of the other modules.
Summing-up: high cohesion often correlates with loose coupling, and viceversa. Software Architecture is to increase cohesion and reduce coupling. In other words, loose coupling and high cohesion provides the best software.
These notes have been taken from:
- The article Coupling (computer programming) (wikipedia).
- The article Cohesion (computer science) (wikipedia).
- The post Why coupling is always bad / Cohesion vs. coupling.