Coupling (computer programming): Difference between revisions

Revision as of 00:51, 6 May 2022

Latest revision as of 13:58, 24 July 2025

(14 intermediate revisions by 9 users not shown)

Line 1:

{{short description|Degree of interdependence between software modules}}

In [[software engineering]], '''coupling''' is the degree of interdependence between software [[Modular programming|modules]];, a measure of how closely connected two routines or modules are;,<ref name="ISO_24765"/> and the strength of the relationships between modules.<ref name="ISOIECTR19759_2005"/> Coupling is not binary but multi-dimensional. <ref name=":0">{{Cite book |last=Hohpe |first=Gregor |title=Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions |publisher=Addison-Wesley Professional |isbn=978-0321200686}}</ref>

[[File:CouplingVsCohesion.svg|thumb|Coupling and [[cohesion (computer science)|cohesion]]]]

Line 23:

;{{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>

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

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

Line 35:

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

== Dimensions of coupling ==

According to Gregor Hohpe, coupling is multi-dimensional:<ref name=":0" />

* Technology Dependency

* Location Dependency

* Topology Dependency

* Data Format & Type Dependency

* Semantic Dependency

* Conversation Dependency

* Order Dependency

* Temporal Dependency

== Disadvantages of tight coupling ==

Line 70 ⟶ 82:

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 (see [[Information Hiding]]).

Systems such as [[CORBA]] or [[Component Object Model|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 vs Connascence ==

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. It evaluates two key dimensions: strength, which measures how difficult it is to change the dependency, and scope (or visibility), which indicates how widely the dependency is exposed across modules or boundaries. Traditional coupling types typically include content coupling, common coupling, control coupling, stamp coupling, external coupling, and data coupling. <ref name=":03">{{Cite book |title=Practical Guide to Structured Systems Design |isbn=978-0136907695}}</ref><ref name=":12">{{Cite book |title=Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems |isbn=978-1449373320}}</ref><ref name=":2">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |isbn=978-1492043454}}</ref>

[[Connascence]], introduced by Meilir Page-Jones, provides a systematic framework for analyzing and measuring coupling dependencies. It evaluates dependencies based on three dimensions: strength, which measures the effort required to refactor or modify the dependency; locality, which considers how physically or logically close dependent components are in the codebase; and degree, which measures how many components are affected by the dependency. Connascence can be categorized into static (detectable at compile-time) and dynamic (detectable at runtime) forms. Static connascence refers to compile-time dependencies, such as method signatures, while dynamic connascence refers to runtime dependencies, which can manifest in forms like connascence of timing, values, or algorithm. <ref name=":03" /><ref name=":12" /><ref name=":2" />

Each coupling flavor can exhibit multiple types of connascence, a specific type, or, in rare cases, none at all, depending on how the dependency is implemented. Common types of connascence include connascence of name, type, position, and meaning. Certain coupling types naturally align with specific connascence types; for example, data coupling often involves connascence of name or type. However, not every combination of coupling and connascence is practically meaningful. Dependencies relying on parameter order in a method signature demonstrate connascence of position, which is fragile and difficult to refactor because reordering parameters breaks the interface. In contrast, connascence of name, which relies on field or parameter names, is generally more resilient to change. Connascence types themselves exhibit a natural hierarchy of strength, with connascence of name typically considered weaker than connascence of meaning. <ref name=":03" /><ref name=":12" /><ref name=":2" />

Dependencies spanning module boundaries or distributed systems typically have higher coordination costs, increasing the difficulty of refactoring and propagating changes across distant boundaries. Modern practices, such as dependency injection and interface-based programming, are often employed to reduce coupling strength and improve the maintainability of dependencies. <ref name=":03" /><ref name=":12" /><ref name=":2" />

While coupling identifies what is shared between components, connascence evaluates how those dependencies behave, how changes propagate, and how difficult they are to refactor. Strength, locality, and degree are interrelated; dependencies with high strength, wide scope, and spanning distant boundaries are significantly harder to refactor and maintain. 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. <ref name=":03" /><ref name=":12" /><ref name=":2" />

== Coupling versus cohesion ==

Line 108 ⟶ 130:

==See also==

* [[Cohesion (computer science)]]

* [[Connascence (computer science)]]

* [[Coupling (physics)]]

Line 128 ⟶ 149:

<ref name="Beck_2011">{{cite book |author-first1=Fabian |author-last1=Beck |author-first2=Stephan |author-last2=Diehl |chapter=On the Congruence of Modularity and Code Coupling |title=In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT/FSE '11) |___location=Szeged, Hungary |date=September 2011 |page=354 |doi=10.1145/2025113.2025162|isbn=9781450304436 |s2cid=2413103 }}</ref>

<ref name="Arisholm_2004">{{cite journal |author-first1=Erik |author-last1=Arisholm |author-first2=Lionel C. |author-last2=Briand |author-link2=Lionel C. Briand |author-first3=Audun |author-last3=Føyen |title=Dynamic coupling measurement for object-oriented software |journal=[[IEEE Transactions on Software Engineering]] |publisher=[[IEEE]] |volume=30 |number=8 |pages=491–506 |date=August 2004 |doi=10.1109/TSE.2004.41|hdl=10852/9090 |s2cid=3074827 |hdl-access=free }}</ref>

<ref name="Pressman_1982">{{cite book |author-last=Pressman |author-first=Roger S. |author-link=Roger S. Pressman |date=1982 |title=Software Engineering - A Practitioner's Approach |publisher=McGraw-Hill |edition=4 |isbn=0-07-052182-4 |url-access=registration |url=https://archive.org/details/softwareengineer00pres_0 }}</ref>

}}

Line 136 ⟶ 157:

* {{Cite book |author-first=Meilir |author-last=Page-Jones |title=The Practical Guide to Structured Systems Design |publisher=Yourdon Press |___location=New York |date=1980 |isbn=978-8-12031482-5}}

* {{Cite book |publisher=[[IEEE]] |title=Standard Glossary of Software Engineering Terminology |id=610.12_1990 |___location=New York |date=1990 |isbn=0-7381-0391-8}}

* {{Cite web |title=Curriculum for Certified Professional for Software Architecture (CPSA) - Foundation Level |publisher=International Software Architecture Qualification Board e.V. (ISAQB) |date=2015-05-15 |orig-year=2009 |version=3.01 |url=https://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Curriculum-foundation-v3-MAY-2015-EN.pdf |access-date=2019-06-23 |archive-date=2017-03-29 |archive-url=https://web.archive.org/web/20170329132933/http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Curriculum-foundation-v3-MAY-2015-EN.pdf |url-status=dead }} [http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Lehrplan-foundation-v3-MAI-2015-DE.pdf] {{Webarchive|url=https://web.archive.org/web/20160222052330/http://www.isaqb.org/wp-content/uploads/2015/05/isaqb-Lehrplan-foundation-v3-MAI-2015-DE.pdf |date=2016-02-22 }}

{{DEFAULTSORT:Coupling (Computer Science)}}