principles:low_coupling
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
principles:low_coupling [2012-12-17 22:45] – added link christian | principles: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: | + | * [[contexts: |
+ | * [[contexts: | ||
+ | * [[contexts: | ||
- | ===== Definition | + | ===== Principle Statement |
[[glossary: | [[glossary: | ||
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 " | ||
+ | |||
+ | 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 | + | Furthermore |
But if coupling is low, there are only few assumptions between the modules which can be violated. This reduces the chance of [[glossary: | But if coupling is low, there are only few assumptions between the modules which can be violated. This reduces the chance of [[glossary: | ||
+ | |||
+ | |||
+ | ===== Strategies ===== | ||
+ | |||
+ | * Indirection: | ||
+ | * Dependency Inversion/ | ||
+ | * Use lower form of coupling | ||
+ | * Merge modules: when there is only one module, then there is no communication and thus no coupling | ||
+ | * Hide information: | ||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | Coupling can be reduced by several technical measures (see [[# | ||
+ | |||
+ | 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, | ||
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
- | / | + | /* |
- | * [[wiki: | + | |
- | * [[wiki: | + | |
- | / | + | * [[wiki: |
+ | * [[wiki: | ||
+ | |||
+ | /* | ||
Line 48: | Line 88: | ||
==== Specializations ==== | ==== Specializations ==== | ||
- | * [[principles: | + | * [[Constantine' |
- | * [[principles: | + | * [[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. |
==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
- | * [[principles:Keep It Simple Stupid]]: Reducing the coupling often involves the use of complicated interaction patterns, indirections, | + | * [[Keep It Simple Stupid]] |
+ | * [[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/ | ||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
- | * [[principles:High Cohesion]] | + | * [[Tell, don't Ask/ |
- | * [[principles:Model Principle]] | + | * [[Model Principle]] |
+ | * [[Information Hiding/ | ||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 64: | Line 106: | ||
{{page> | {{page> | ||
{{page> | {{page> | ||
+ | {{page> | ||
- | ===== 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: | + | /*[[wiki: |
- | / | + | |
+ | [[wiki: | ||
/ | / | ||
===== Further Reading ===== | ===== Further Reading ===== | ||
- | * Albert Endres and Dieter Rombach: //A Handbook of Software and Systems Engineering// | + | * Albert Endres and Dieter Rombach: //[[resources: |
* [[wp> | * [[wp> | ||
* [[wiki> | * [[wiki> | ||
* Martin Fowler: // | * Martin Fowler: // | ||
+ | * {{page> | ||
+ | |||
+ | ===== Discussion ===== | ||
+ | |||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/low_coupling.txt · Last modified: 2021-10-18 21:49 by christian