User Tools

Site Tools


principles:low_coupling

This is an old revision of the document!


Low Coupling (LC)

Variants and Alternative Names

  • Loose Coupling

Context

Principle Statement

Coupling between modules should be low.

Description

A module should not interact with too many other modules. Furthermore if a module A interacts with another module B, this interaction should be loose, which means that A should not make too many assumptions about B.

Rationale

If a module A interacts with a module B, there is a certain dependency between these modules. When for example A uses a certain functionality of B, then A depends on B. A makes the assumption that B provides a certain service, and moreover it makes assumptions on how this service can be used (by which mechanism, which parameters, etc.). If one of these assumptions is not true anymore because B has changed for some reason, A also has to change. So the fewer dependencies there are, the less likely it is that A stops working and has to be changed.

Furthermore A makes many and detailed assumptions about B, there is also a high probability that A has to change despite only relying one one other module. This is because in such a case A also needs to change when only a certain detail of B changes.

But if coupling is low, there are only few assumptions between the modules which can be violated. This reduces the chance of ripple effects.

Strategies

  • Indirection:
  • Dependency Inversion/Abstract Couplings:
  • Use lower form of coupling:
  • Merge modules:
  • Hide information

Caveats

Coupling can be reduced by several technical measures (see strategies). But while these measures reduce the coupling technically, they do not necessarily reduce the logical coupling. In such a case two modules A and B may seem decoupled, but ripple effects may occur anyway because of the logical coupling. In such a case it is better to make the coupling explicit by not applying a decoupling strategy. It may also be possible to find a better suitable strategy or a better way of applying the strategy to also get rid of the logical coupling.

Furthermore note that coupling to a stable module is often no problem. The problematic cases are couplings to unstable modules. This means that applying decoupling strategies is beneficial when a coupling to an unstable module is reduced. But it may not be beneficial in the other cases.

See also section contrary principles.

Origin

Evidence

  • Accepted: The concept of low coupling is widely known and described in several well-known books for example in Craig Larman's Applying UML and Patterns

Relations to Other Principles

Generalizations

Specializations

  • Constantine's Law: Constantine's Law is just the combination of the two principles LC and HC.
  • Dependency Inversion Principle (DIP): LC aims at reducing the dependencies to other modules. One way to do so is to only depend on abstractions. DIP is about this aspect.

Contrary Principles

  • Keep It Simple Stupid (KISS): Reducing the coupling often involves the use of complicated interaction patterns, indirections, etc.
  • High Cohesion (HC): A system consisting of one single module has a very low coupling as there are no dependencies on other modules. But such a system also has low cohesion. The other extreme, very many highly cohesive modules, naturally has a higher coupling between the modules. So here a compromise has to be found.
  • Rule of Explicitness (RoE): Direct communication typically has the disadvantage of a higher coupling. Indirection reduces coupling but creates implicit/indirect communication paths.

Complementary Principles

Principle Collections

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU

Examples

Description Status

Further Reading

principles/low_coupling.1599677394.txt.gz · Last modified: 2020-09-09 20:49 by 35.202.2.1