User Tools

Site Tools


This is an old revision of the document!

Low Coupling (LC)

Variants and Alternative Names

  • Loose Coupling


Principle Statement

Coupling between modules should be low.


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.


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.


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


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.



  • 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



  • 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 Modularization Principles


Description Status

Further Reading

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