User Tools

Site Tools


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
principles:low_coupling [2013-02-25 14:05] – added source christianprinciples:low_coupling [2021-10-18 21:49] (current) – +++ restored +++ 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.1361797550.txt.gz · Last modified: 2013-05-19 22:10 (external edit)