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
Next revisionBoth sides next revision
principles:low_coupling [2014-07-14 13:19] – [Rationale] 2001:8d8:1fe:100:fc69:ab47:c44c:75d1principles:low_coupling [2020-10-12 19:54] – old revision restored (2013-02-12 17:13) 159.69.186.191
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 20: Line 18:
  
 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 46: Line 24:
 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 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.+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]]. 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 53: Line 31:
 ===== Strategies ===== ===== Strategies =====
  
-  * Indirection: Don't access the other module directly but have another module do that.+  * Indirection: 
   * Dependency Inversion/Abstract Couplings:   * Dependency Inversion/Abstract Couplings:
-  * Use lower form of coupling +  * Use lower form of coupling: 
-  * Merge modules: when there is only one module, then there is no communication and thus no coupling +  * Merge modules: 
-  * Hide information: Information which is hidden cannot be depended upon. +  * 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 ===== ===== Origin =====
 /* the *primary* source */ /* the *primary* source */
-  * W. P. Stevens,  G. J. Myers, L. L. Constantine: //Structured design//+
  
 ===== Evidence ===== ===== Evidence =====
Line 76: Line 45:
 /*  * [[wiki:Proposed]]*/ /*  * [[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:Examined]] 
-  * [[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:Accepted]]
  
 /*  * [[wiki:Questioned]]*/ /*  * [[wiki:Questioned]]*/
Line 88: Line 57:
 ==== Specializations ==== ==== Specializations ====
  
 +  * [[Tell, don't Ask/Information Expert]] (TdA/IE): Adhering to the information expert principle leads to low coupling as there is less need to communicate with other modules to get the necessary information.
   * [[Constantine's Law]]: Constantine's Law is just the combination of the two principles LC and HC.   * [[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.   * [[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.
Line 95: Line 65:
   * [[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 ====
  
-  * [[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.   * [[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.   * [[Information Hiding/Encapsulation]] (IH/E): Higher forms of couplings (especially content couplings) break encapsulation.
Line 108: Line 77:
 {{page>collections:Principles in "The Pragmatic Programmer"#Box}} {{page>collections:Principles in "The Pragmatic Programmer"#Box}}
  
-===== Examples =====+===== Example =====
  
  
 ===== 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: //[[resources:A Handbook of Software and Systems Engineering]]//. p. 43pp.+  * Albert Endres and Dieter Rombach: //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]]// 
-  * {{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