Coupling (computer programming): Difference between revisions

Revision as of 04:36, 24 December 2024

Latest revision as of 13:58, 24 July 2025

(4 intermediate revisions by 3 users not shown)

Line 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 both what they share (e.g., data, control flow, technology) and how tightly they're are bound. It evaluates two key dimensions: strength, which measures (how difficult it is to change the dependency), and directnessscope (whetheror dependenciesvisibility), arewhich directindicates how widely the dependency is exposed across modules or indirect)boundaries. Traditional coupling types, ranked from strongest to weakest,typically include content coupling, common coupling, externalcontrol coupling, controlstamp coupling, stampexternal coupling, and data coupling. <ref name=":0203">{{Cite book |title=Practical Guide to Structured Systems Design |isbn=978-0136907695}}</ref><ref name=":112">{{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 formal and systematic framework for analyzing and classifyingmeasuring coupling dependencies. Rather than being separate from coupling, Connascence serves as a granular metric for measuring coupling strength and resilience. It evaluates dependencies alongbased twoon keythree dimensions: strength, which measures the effort neededrequired to refactor or changemodify the dependency, and; locality, which considers how physically closeor thelogically 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=":0212" /><ref name=":12" />

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" />

Connascence can be further divided into static and dynamic forms. Static Connascence refers to dependencies detectable at compile-time, such as method signatures, while dynamic Connascence refers to dependencies visible only at runtime, such as dynamic behavior in polymorphic code. <ref name=":02" /><ref name=":1" />

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" />

When two components depend on parameter order in a method signature, they exhibit Connascence of Position, a form of dependency that is fragile and difficult to refactor because reordering breaks the interface. In contrast, Connascence of Name relies on parameter or field names, making it more resilient to changes. Two services using a shared JSON API often exhibit data coupling, and beyond that, semantic coupling, which refers to the shared meaning and interpretation of the data being exchanged. Modern API designs often favor Connascence of Name over Connascence of Position to improve resilience against change. <ref name=":02" /><ref name=":1" />

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" />

In essence, coupling maps the dependency landscape, identifying how components are connected. Connascence systematically measures and classifies these dependencies, providing deeper insights into their strength, locality, and resilience to change. Together, they offer complementary perspectives for designing maintainable, robust systems. <ref name=":02" /><ref name=":1" />

== Coupling versus cohesion ==

Line 131 ⟶ 130:

==See also==

* [[Cohesion (computer science)]]

* [[Connascence (computer science)]]

* [[Coupling (physics)]]