Low-Coupling / High-Cohesion pattern

In computer science, the Low-Coupling / High-Cohesion isn t a specific pattern amongst design pattern (computing)s. It s a general method for structuring Computer programs so that they re simpler to understand, program and maintain.

These concepts (Low-Coupling / High-Cohesion) are usually related. Low coupling implies high cohesion and viceversa, because if we put together all relationed methods (High Cohesion), the connection between classes tends to get lower (Low Coupling).

= Low Coupling =

Coupling is a measure of how strongly one class is connected to another and is increased between Class A and Class B when:

*A has an attribute that refers to (is of type) B. *A calls on services of a B object. *A has a method which references B (via return type or parameter). *A is a subclass of (or implements) B.

The disadvantages of high coupling includes:

*A change in one class forces a ripple of changes in other classes. *Difficult to understand a class in isolation. *Difficult to reuse a class because dependent class must also be included.

= High Cohesion =

If we want to design classes to increase the likelihood of reuse and not be overwhelmingly complex, keeping complexity manageable, the solution is assigning responsibilities so that cohesion remains high.

Cohesion is a measure of how strongly related and focused the responsibilities of a single class are. Cohesion is decreased when:

*The responsibilities (operations) of a class have little in common. *Operations do many varied activities, often using varied data.

The disadvantages of weak cohesion are:

*Difficult to understand. *Difficult to maintain, because it is constantly affected by changes. *Difficult to reuse a class because most application wont need a random set of operations attached to a class.

= Related patterns =

Although low coupling is a desirable goal, and this goal provides useful guidance, the description of the pattern does not tell how to actually achieve low-coupled design in most cases. Functional design limits the responsibilities of modules. Modules with single responsibilities usually need to communicate less with other modules, and this has the virtuous side-effect of reducing coupling and increasing cohesion in many cases.