Editing Coupling (computer programming) (section)

== Types of coupling ==
{{anchor|Tramp coupling|Pathological coupling|Content coupling|Common-environment coupling|Hybrid coupling|Structural coupling|Temporal coupling|Data type coupling|Hardware coupling}}
[[Image:Coupling sketches cropped 1.svg|thumb|300px|right|upright=2.0|Conceptual model of coupling]]
Coupling can be "low" (also "[[loose coupling|loose]]" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

=== Procedural programming ===
A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.

;{{anchor|Content coupling}}Content coupling (high): Content coupling is said to occur when one module uses the code of another module, for instance a branch. This violates [[information hiding]] – a basic software design concept.
;{{anchor|Common coupling}}Common coupling: Common coupling is said to occur when several modules have access to the same global data. But it can lead to uncontrolled error propagation and unforeseen side-effects when changes are made.
;{{anchor|External coupling}}External coupling: External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.
;{{anchor|Control coupling}}Control coupling: Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag).
;{{anchor|Stamp coupling|data-structured coupling}}Stamp coupling (data-structured coupling): Stamp coupling occurs when modules share a composite data structure and use only parts of it, possibly different parts (e.g., passing a whole record to a function that needs only one field of it).
:In this situation, a modification in a field that a module does not need may lead to changing the way the module reads the record. To illustrate the concept of stamp coupling, consider a scenario involving a <code>UserProfile</code> [[Software component|component]]. This component is designed to return the entire user profile information in response to [[HTTP|requests]], even when [[User agent|consumers]] only require a specific [[Attribute (computing)|attribute]]. This practice exemplifies stamp coupling, which can lead to significant [[Bandwidth (computing)|bandwidth]] issues, especially at scale. When any attribute within the <code>UserProfile</code> component changes, all consumers that interact with it may need to undergo [[Software testing|testing]], even if they do not utilize the modified attribute. <ref>{{Cite book |last=Richards |first=Mark |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |isbn=978-1492043454}}</ref>
;{{anchor|Data coupling}}Data coupling: Data coupling occurs when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).

=== Object-oriented programming ===
;{{anchor|Subclass coupling}}Subclass coupling: Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.

;{{anchor|Temporal coupling}}Temporal coupling: It is when two actions are bundled together into one module just because they happen to occur at the same time.

In recent work various other coupling concepts have been investigated and used as indicators for different modularization principles used in practice.<ref name="Beck_2011"/>

==== Dynamic coupling ====
<!-- Section title used in redirects -->
The goal of defining and measuring this type of coupling is to provide a run-time evaluation of a software system. It has been argued that static coupling metrics lose precision when dealing with an intensive use of dynamic binding or inheritance.<ref name="Arisholm_2004"/> In the attempt to solve this issue, dynamic coupling measures have been taken into account.

==== Semantic coupling ====
<!-- Section title used in redirects -->
This kind of a coupling metric considers the conceptual similarities between software entities using, for example, comments and identifiers and relying on techniques such as [[latent semantic indexing]] (LSI).

==== Logical coupling ====
<!-- Section title used in redirects -->
{{anchor|evolutionary coupling|Change coupling}}Logical coupling (or evolutionary coupling or change coupling) analysis exploits the release history of a software system to find change patterns among modules or classes: e.g., entities that are likely to be changed together or sequences of changes (a change in a class A is always followed by a change in a class B).