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
Next revisionBoth sides next revision
principles:low_coupling [2012-12-17 22:45] – added link christianprinciples:low_coupling [2021-09-02 12:46] – old revision restored (2021-03-29 09:33) 65.21.179.175
Line 10: Line 10:
  
  
-===== Definition =====+===== Principle Statement =====
  
 [[glossary:Coupling]] between [[glossary:modules]] should be low. [[glossary:Coupling]] between [[glossary:modules]] should be low.
Line 27: Line 27:
  
 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]].
 +
 +
 +===== Strategies =====
 +
 +  * Indirection: 
 +  * Dependency Inversion/Abstract Couplings:
 +  * Use lower form of coupling:
 +  * Merge modules:
 +  * 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]].
  
  
Line 35: Line 52:
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* Comment out what is not applicable and explain the rest: */
-/*[[wiki:Proposed]]*/+/*  * [[wiki:Proposed]]*/ 
   * [[wiki:Examined]]   * [[wiki:Examined]]
-  * [[wiki:Accepted]]+  * [[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 48: Line 66:
 ==== Specializations ==== ==== Specializations ====
  
-  * [[principles:Information Expert]] +  * [[Constantine's Law]]: Constantine's Law is just the combination of the two principles LC and HC. 
-  * [[principles:Constantine's Law]]+  * [[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, 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. 
 +  * [[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 ====
  
-  * [[principles:High Cohesion]] +  * [[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]]). 
-  * [[principles:Model Principle]]+  * [[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.
  
 ==== Principle Collections ==== ==== Principle Collections ====
Line 64: Line 84:
 {{page>collections:OOD Principle Language#Box}} {{page>collections:OOD Principle Language#Box}}
 {{page>collections:GRASP#Box}} {{page>collections:GRASP#Box}}
 +{{page>collections:Principles in "The Pragmatic Programmer"#Box}}
  
-===== Example =====+===== Examples =====
  
  
Line 80: Line 101:
   * [[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//
 +
principles/low_coupling.txt · Last modified: 2021-10-18 21:49 by christian