Coupling (computer programming)

Low coupling often correlates with high cohesion, and vice versa.

Low coupling is often thought to be 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.

[citation needed] 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.

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong").

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.

In recent work various other coupling concepts have been investigated and used as indicators for different modularization principles used in practice.

[7] 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.

[8] In the attempt to solve this issue, dynamic coupling measures have been taken into account.

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).

According to Gregor Hohpe, coupling is multi-dimensional:[3] Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages: Whether loosely or tightly coupled, a system's performance is often reduced by message and parameter creation, transmission, translation (e.g. marshaling) and message interpretation (which might be a reference to a string, array or data structure), which require less overhead than creating a complicated message such as a SOAP message.

Coupling describes the degree and nature of dependency between software components, focusing on what they share (e.g., data, control flow, technology) and how tightly they are bound.

[9][10][11] Connascence, introduced by Meilir Page-Jones, provides a systematic framework for analyzing and measuring coupling dependencies.

[9][10][11] While coupling identifies what is shared between components, connascence evaluates how those dependencies behave, how changes propagate, and how difficult they are to refactor.

Together, coupling provides a high-level overview of dependency relationships, while connascence offers a granular framework for analyzing dependency strength, locality, degree, and resilience to change, supporting the design of maintainable and robust systems.

Coupling in Software Engineering[12] describes a version of metrics associated with this concept.