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]]
  * [[contexts:API Design]]
  * [[contexts:Architecture]]


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

Coupling is a measure of dependency between modules. The more dependencies there are, the stronger the dependencies are, and the more assumptions are made upon other modules, the higher is the coupling.

There are different forms of couplings which can be rated according to their strength((G. J. Myers: //Reliable Software through Composite Design//)):

  * //No coupling//: The modules do not know each other.
  * //Call coupling//: A module calls another one.
  * //Data coupling//: A module calls another one passing parameters to it.
  * //Stamp coupling//: A module calls another one passing complex parameters to it.
  * //Control coupling//: A module influences the control flow of another module.
  * //External coupling//: The modules communicate using a simple global variable.
  * //Common coupling//: The modules communicate using a common global data structure.
  * //Content coupling//: A modules depends on the inner working of another module. This is the strongest form of coupling.

The forms ranging from no coupling to stamp coupling can be considered "good" couplings. The others are rather strong.

There are also some additional forms of undesirable couplings:

  * //Tramp coupling//: A module is only coupled to a data structure because some other module needs the data. The module gets the data and passes it to the other module without touching the "tramp data" ((M. Page-Jones: //The Practical Guide to Structured Systems Design//)).
  * //Logical coupling//: A module makes some assumptions about another module without referencing it. For example a module //A// only sorts a list because some other module //B// which //A// technically does not know about needs it sorted.


===== 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 if //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: Don't access the other module directly but have another module do that.
  * Dependency Inversion/Abstract Couplings:
  * Use lower form of coupling
  * Merge modules: when there is only one module, then there is no communication and thus no coupling
  * Hide information: Information which is hidden cannot be depended upon.

===== 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 */
  * W. P. Stevens,  G. J. Myers, L. L. Constantine: //Structured design//

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

  * [[wiki:Examined]]: There are metrics that try to measure coupling and there are studies relating these coupling measures to the number of errors found during testing (({{page>resources:A Handbook Of Software And Systems Engineering#reference}})). This correlation is evident. The limitation of these studies is that these coupling metrics cannot represent the coupling notion completely.
  * [[wiki:Accepted]]: The concept of low coupling is widely known and described in several well-known books for example in {{page>resources:Applying UML And Patterns#reference}}.

/*  * [[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: //[[resources: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]]// 
  * {{page>resources:Applying UML And Patterns#reference}}

===== Discussion =====

Discuss this wiki article and the principle on the corresponding [[talk:principles:Low Coupling|talk page]].