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 revisionBoth sides next revision
principles:low_coupling [2020-02-17 22:55] – Implementation coupling is called "content coupling" and already in the list christianprinciples:low_coupling [2020-09-09 20:49] – old revision restored (2013-05-19 22:09) 35.202.2.1
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 ===== ===== Caveats =====
Line 70: Line 48:
 ===== Origin ===== ===== Origin =====
 /* the *primary* source */ /* the *primary* source */
-  * W. P. Stevens,  G. J. Myers, L. L. Constantine: //Structured design//+
  
 ===== Evidence ===== ===== Evidence =====
Line 76: Line 54:
 /*  * [[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]]: The concept of low coupling is widely known and described in several well-known books for example in Craig Larman's //Applying UML and Patterns//
  
 /*  * [[wiki:Questioned]]*/ /*  * [[wiki:Questioned]]*/
Line 113: Line 91:
 ===== 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}} +  * Craig Larman//Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//
- +
-===== 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