Coupling and Cohesion

Do things that belong together, occur together?

Cohesion is often contrasted with Coupling.

Coupling refers to the inter-dependencies between modules, while cohesion describes how related the functions within a single module are.

Coupling

Coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often thought to be a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

• A change in one module usually forces a ripple effect of changes in other modules.
• Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
• A particular module might be harder to reuse and/or test because dependent modules must be included.

Coupling increases between two classes A and B if:

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

Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation.

One approach to decreasing coupling is functional design, which seeks to limit the responsibilities of modules along functionality. A functional design assures that each modular part of a device has only one responsibility and performs that responsibility with the minimum of side effects on other parts.

The advantage for implementation is that if a software module has a single purpose, it will be simpler, and therefore easier and less expensive, to design and implement.

Systems with functionally designed parts are easier to modify because each part does only what it claims to do.

Since maintenance is more than 3/4 of a successful system's life, this feature is a crucial advantage. It also makes the system easier to understand and document, which simplifies training. The result is that the practical lifetime of a functional system is longer.

In a system of programs, a functional module will be easier to reuse because it is less likely to have side effects that appear in other parts of the system.

The standard way to assure functional design is to review the description of a module. If the description includes conjunctions such as "and" or "or", then the design has more than one responsibility, and is therefore likely to have side effects. The responsibilities need to be divided into several modules in order to achieve a functional design.

Cohesion

Cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class's methods and data themselves.

Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. 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. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

High cohesion often correlates with loose coupling, and vice versa. Low cohesion implies that a given module performs tasks which are not very related to each other and hence can create problems as the module becomes large.

In object-oriented programming, if the methods that serve a class tend to be similar in many aspects, then the class is said to have high cohesion. In a highly cohesive system, code readability and reusability is increased, while complexity is kept manageable.

Cohesion is increased if:

• The functionalities embedded in a class, accessed through its methods, have much in common.
• Methods carry out a small number of related activities, by avoiding coarsely grained or unrelated sets of data.
• Related methods are in the same source file or otherwise grouped together; for example, in separate files but in the same sub-directory/folder.

Advantages of high cohesion (or "strong cohesion") are:

• Reduced module complexity (they are simpler, having fewer operations).
• Increased system maintainability, because logical changes in the domain affect fewer modules, and because changes in one module require fewer changes in other modules.
• Increased module reusability, because application developers will find the component they need more easily among the cohesive set of operations provided by the module.

While in principle a module can have perfect cohesion by only consisting of a single, atomic element – having a single function, for example – in practice complex tasks are not expressible by a single, simple element. Thus a single-element module has an element that either is too complicated, in order to accomplish a task, or is too narrow, and thus tightly coupled to other modules. Thus cohesion is balanced with both unit complexity and coupling.

Highly cohesive code-bases conform to the single responsibility principle, which suggests that units of code should have exactly one reason to change, and to change for only that reason. But, beyond that, they localize changes as much as possible.

Resource

• [ ] https://en.wikipedia.org/wiki/Coupling_(computer_programming)
• [ ] https://en.wikipedia.org/wiki/Cohesion_(computer_science)
• [ ] https://www.infoq.com/news/2009/04/coupling
• [ ] https://blog.knoldus.com/know-about-temporal-coupling-the-design-smell
• [ ] https://wiki.c2.com/?CouplingAndCohesion
• [ ] https://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling
• [ ] https://www.d.umn.edu/~gshute/softeng/presentations/temporal-coupling.xhtml
• [ ] https://www.pluralsight.com/tech-blog/forms-of-temporal-coupling
• [ ] https://enterprisecraftsmanship.com/posts/temporal-coupling-and-immutability
• [ ] https://tidyfirst.substack.com/p/tldr-cohesion

@BethCodes simple summary of coupling and cohesion:

how many things change, with each additional thing making the change less safe, and how much of each thing, with more of each thing making the change safer

"Belong together" is too vague to be useful when I try to explain cohesion. "Change at the same time" is an empirical, observable fact. - Kent Beck