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 [2020-10-12 14:24] – old revision restored (2013-02-18 17:24) 159.69.186.191principles: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 =====
  
-See section [[#contrary principles]].+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 50: 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 62: Line 88:
 ==== 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 70: 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 ====
  
 +  * [[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 82: 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]]// 
 +  * {{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.1602505456.txt.gz · Last modified: 2020-10-12 14:24 by 159.69.186.191