In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules. Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.
The software quality metrics of coupling and cohesion were invented by Larry Constantine in the late 1960s as part of a structured design, based on characteristics of “good” programming practices that reduced maintenance and modification costs. Structured design, including cohesion and coupling, were published in the article Stevens, Myers & Constantine and the book Yourdon & Constantine, and the latter subsequently became standard terms.
Types of coupling
Coupling can be "low" or "high". Some types of coupling, in order of highest to lowest coupling, are as follows:
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. ;Content coupling : 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 design concept. ;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. ;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. ;Control coupling: Control coupling is one module controlling the flow of another, by passing it information on what to do. ;Stamp coupling : Stamp coupling occurs when modules share a composite data structure and use only parts of it, possibly different parts. ;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.
;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. ;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.
The goal of 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. In the attempt to solve this issue, dynamic coupling measures have been taken into account.
This kind of coupling considers the conceptual similarities between software entities using, for example, comments and identifiers and relying on techniques such as Latent Semantic Indexing.
Logical coupling 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.
Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:
A change in one module usually forces a ripple effect of changes in other modules.
Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
A particular module might be harder to reuse and/or test because dependent modules must be included.
Whether loosely or tightly coupled, a system's performance is often reduced by message and parameter creation, transmission, translation and message interpretation, which require less overhead than creating a complicated message such as a SOAP message. Longer messages require more CPU and memory to produce. To optimize runtime performance, message length must be minimized and message meaning must be maximized. ;Message Transmission Overhead and Performance: Since a message must be transmitted in full to retain its complete meaning, message transmission must be optimized. Longer messages require more CPU and memory to transmit and receive. Also, when necessary, receivers must reassemble a message into its original state to completely receive it. Hence, to optimize runtime performance, message length must be minimized and message meaning must be maximized. ;Message Translation Overhead and Performance: Message protocols and messages themselves often contain extra information. Hence, the receiver often needs to translate a message into a more refined form by removing extra characters and structure information and/or by converting values from one type to another. Any sort of translation increases CPU and/or memory overhead. To optimize runtime performance, message form and content must be reduced and refined to maximize its meaning and reduce translation. ;Message Interpretation Overhead and Performance: All messages must be interpreted by the receiver. Simple messages such as integers might not require additional processing to be interpreted. However, complex messages such as SOAP messages require a parser and a string transformer for them to exhibit intended meanings. To optimize runtime performance, messages must be refined and reduced to minimize interpretation overhead.
One approach to decreasing coupling is functional design, which seeks to limit the responsibilities of modules along functionality. Coupling increases between two classes A and B if:
A has an attribute that refers to B.
A calls on services of an object B.
A has a method that references B.
A is a subclass of class B.
Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation. Systems such as CORBA or COM allow objects to communicate with each other without having to know anything about the other object's implementation. Both of these systems even allow for objects to communicate with objects written in other languages.
Coupling versus cohesion
Coupling and cohesion are terms which occur together very frequently. Coupling refers to the interdependencies between modules, while cohesion describes how related the functions within a single module are. Low cohesion implies that a given module performs tasks which are not very related to each other and hence can create problems as the module becomes large.
r: number of modules calling the module under consideration
Coupling makes the value larger the more coupled the module is. This number ranges from approximately 0.67 to 1.0 For example, if a module has only a single input and output data parameter If a module has 5 input and output data parameters, an equal number of control parameters, and accesses 10 items of global data, with a fan-in of 3 and a fan-out of 4,