Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Low Coupling (LC)
principles:low_coupling

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
principles:low_coupling [2013-02-25 14:05] – added source christianprinciples:low_coupling [2021-10-18 21:49] – old revision restored (2020-02-17 22:55) christian
Line 7: Line 7:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:Architecture]]
  
  
Line 18: Line 20:
  
 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//. 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.
  
  
Line 24: Line 46:
 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.  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.+Furthermore if //A// makes many and detailed assumptions about //B//, there is also a high probability that //A// has to change despite only relying on 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]]. 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]].
Line 31: Line 53:
 ===== Strategies ===== ===== Strategies =====
  
-  * Indirection: +  * Indirection: Don't access the other module directly but have another module do that.
   * Dependency Inversion/Abstract Couplings:   * Dependency Inversion/Abstract Couplings:
-  * Use lower form of coupling: +  * Use lower form of coupling 
-  * Merge modules: +  * Merge modules: when there is only one module, then there is no communication and thus no coupling 
-  * Hide information+  * Hide information: Information which is hidden cannot be depended upon.
  
 ===== Caveats ===== ===== Caveats =====
Line 48: Line 70:
 ===== Origin ===== ===== Origin =====
 /* the *primary* source */ /* the *primary* source */
 +  * W. P. Stevens,  G. J. Myers, L. L. Constantine: //Structured design//
  
 ===== Evidence ===== ===== Evidence =====
Line 54: Line 76:
 /*  * [[wiki:Proposed]]*/ /*  * [[wiki:Proposed]]*/
  
-  * [[wiki:Examined]] +  * [[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]]+  * [[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]]*/ /*  * [[wiki:Questioned]]*/
Line 73: Line 95:
   * [[Keep It Simple Stupid]] (KISS): Reducing the coupling often involves the use of complicated interaction patterns, indirections, etc.   * [[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.   * [[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 ==== ==== Complementary Principles ====
  
Line 86: Line 108:
 {{page>collections:Principles in "The Pragmatic Programmer"#Box}} {{page>collections:Principles in "The Pragmatic Programmer"#Box}}
  
-===== Example =====+===== Examples =====
  
  
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]] +/*[[wiki:Stub]]/* 
-/*[[wiki:Incomplete]]*/+ 
 +[[wiki:Incomplete]] 
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
  
 ===== Further Reading ===== ===== Further Reading =====
  
-  * Albert Endres and Dieter Rombach: //A Handbook of Software and Systems Engineering//. p. 43pp.+  * Albert Endres and Dieter Rombach: //[[resources:A Handbook of Software and Systems Engineering]]//. p. 43pp.
   * [[wp>Loose coupling]], [[wp>Coupling (computer programming)]]   * [[wp>Loose coupling]], [[wp>Coupling (computer programming)]]
   * [[wiki>CouplingAndCohesion]]   * [[wiki>CouplingAndCohesion]]
   * Martin Fowler: //[[http://martinfowler.com/ieeeSoftware/coupling.pdf|Reducing Coupling]]//    * 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//+  * {{page>resources:Applying UML And Patterns#reference}} 
 + 
 +===== Discussion ===== 
 + 
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Low Coupling|talk page]].
principles/low_coupling.txt · Last modified: 2021-10-18 21:49 by christian