Principles Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Low Coupling (LC) ======

===== Variants and Alternative Names =====

  * Loose Coupling

===== Context =====
/* fill in contexts here: */
  * [[contexts:Object-Oriented Design]] 


===== Principle Statement =====

[[glossary:Coupling]] between [[glossary: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 [[glossary: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 =====
/* the *primary* source */


===== Evidence =====
/* Comment out what is not applicable and explain the rest: */
/*  * [[wiki:Proposed]]*/

  * [[wiki:Examined]]
  * [[wiki: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//

/*  * [[wiki:Questioned]]*/


===== 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 ====

  * [[Tell, don't Ask/Information Expert]] (TdA/IE): IE may help to reduce coupling. Although there are also contrary cases (see [[Tell, don't Ask/Information Expert#caveats]]).
  * [[Model Principle]] (MP): LC aims at reducing the dependencies to other modules. So a module shall depend on only a few others. MP now tells which dependencies are allowed and which aren't.
  * [[Information Hiding/Encapsulation]] (IH/E): Higher forms of couplings (especially content couplings) break encapsulation.

==== Principle Collections ====

{{page>collections:OOD Principle Language#Box}}
{{page>collections:GRASP#Box}}
{{page>collections:Principles in "The Pragmatic Programmer"#Box}}

===== Examples =====


===== Description Status =====
/* Choose one of the following and comment out the rest: */
[[wiki:Stub]]
/*[[wiki:Incomplete]]*/
/*[[wiki:Complete]]*/

===== Further Reading =====

  * Albert Endres and Dieter Rombach: //A Handbook of Software and Systems Engineering//. p. 43pp.
  * [[wp>Loose coupling]], [[wp>Coupling (computer programming)]]
  * [[wiki>CouplingAndCohesion]]
  * Martin Fowler: //[[http://martinfowler.com/ieeeSoftware/coupling.pdf|Reducing Coupling]]// 
  * Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//