Coupling is a measure for the strength of the dependencies between modules.
There are plenty of different types of couplings. These are the classic ones ordered from loose to tight1):
|No coupling||The modules do not know each other.||good|
|Call coupling||A module calls another one.||good|
|Data coupling||A module calls another one passing parameters to it.||good|
|Stamp coupling||A module calls another one passing complex parameters to it.||good|
|Control coupling||A module influences the control flow of another module.||bad or OK|
|External coupling||The modules communicate using a simple global variable.||bad|
|Common coupling||The modules communicate using a common global data structure.||bad|
|Content coupling||A modules depends on the inner working of another module. This is the strongest form of coupling.||extremely bad|
Up to control coupling they can be considered “good” couplings, although the lower the coupling the better (see Low Coupling).
Then there are also some special types of 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”2)||bad|
|Hybrid Coupling||A parameter (or return type) is data and control flow information at the same time.||partly bad|
|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.||bad|
|Natural Coupling||A natural coupling is a coupling between classes which represent concepts which are dependent in the same way.||good|
|Artificial Coupling||An artificial coupling is a coupling which is only there for technical reasons.||bad|
|Abstract Coupling||A design pattern using||good|
Discuss this wiki article and the term on the corresponding talk page.