Skip to content

Instantly share code, notes, and snippets.

@pedrofurla
Last active December 13, 2016 05:26
Show Gist options
  • Save pedrofurla/0e42fdc8c2c60a12ea637ae8aae723db to your computer and use it in GitHub Desktop.
Save pedrofurla/0e42fdc8c2c60a12ea637ae8aae723db to your computer and use it in GitHub Desktop.
Coupling vs Cohesion

Quoting Wikipedia: https://en.wikipedia.org/wiki/Cohesion_(computer_science)


In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highly cohesive systems functionality is strongly related.

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.

Cohesion is often contrasted with coupling, a different concept. High cohesion often correlates with loose coupling, and vice versa. The software metrics of coupling and cohesion were invented by Larry Constantine in the late 1960s as part of Structured Design, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured Design, cohesion and coupling were published in the article Stevens, Myers & Constantine (1974) and the book Yourdon & Constantine (1979); the latter two subsequently became standard terms in software engineering.


My take: high cohesion means a module has a very specific inherently interdependent task(s) and concerns and only achieve that and absolutely nothing more.

Various quotings from https://en.wikipedia.org/wiki/Coupling_(computer_programming)


In software engineering, 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 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.

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

Procedural programming

A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.

  1. Content coupling (high) Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). In this situation, a change in the way the second module produces data (location, type, timing) might also require a change in the dependent module.

  2. Common coupling Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource might imply changing all the modules using it.

    ...

  3. Data coupling Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).

  4. Message coupling (low) This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing.

Various quotings from https://en.wikipedia.org/wiki/Coupling_(computer_programming)
---------------------------------
In software engineering, **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 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.
Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:
#### **Procedural programming**
A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.
1. **Content coupling (high)**
Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). In this situation, a change in the way the second module produces data (location, type, timing) might also require a change in the dependent module.
2. **Common coupling**
Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable). Changing the shared resource might imply changing all the modules using it.
...
3. **Data coupling**
Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).
4. **Message coupling (low)**
This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment