Manu's Vault

Coupling

3 min readStatus:Seedling

Core Idea

Coupling measures how dependent modules are on each other. Low coupling means modules can change independently; high coupling means changes in one module force changes in others.

Definition

Coupling is a fundamental metric for evaluating software modularity. It measures the degree of interdependence between software modules — answering: “If I change this module, how many other modules must also change?”

First formally articulated by Larry Constantine in structured design methodology, coupling remains central to modern architecture evaluation.

Key Characteristics

  • Loose coupling (desirable): modules interact through well-defined interfaces, making minimal assumptions about each other’s internals — enabling independent modification, testing, and deployment without cascading changes
  • Tight coupling (problematic): modules know too much about each other’s internals — changing one often requires simultaneous changes to many others, amplifying maintenance costs and bug risk
  • The spectrum: tight end = modules sharing global state or directly accessing internal data structures; loose end = modules communicating only through message passing or well-defined APIs with no shared state
  • Relationship to Cohesion: high cohesion groups related functionality within modules; low coupling minimizes dependencies between modules — together they guide architects toward systems that are internally focused yet externally independent

Why It Matters

  • Change impact: in low-coupling architectures, teams modify individual modules without coordinating across the codebase — reduced blast radius, parallel work by multiple teams, accelerated velocity
  • Change amplification risk: high coupling causes localized changes to ripple through the system, requiring modifications to numerous modules and increasing regression risk; in extreme cases, even minor changes become prohibitively risky
  • Testability: loosely coupled modules can be tested in isolation using mocks or stubs; tightly coupled code requires standing up large portions of the system to verify a single module
  • Architecture style trade-offs: monolithic architectures accept higher coupling for simpler deployment; distributed architectures prioritize loose coupling for independent deployment and scaling

Types of Coupling

Traditional taxonomy (strongest to weakest): content, common, control, stamp, data, message coupling. Modern forms: afferent/efferent, static/dynamic, semantic, implementation. See Stamp-Coupling, Static-Coupling, Dynamic-Coupling, Semantic-Coupling, Implementation-Coupling, Orthogonal-Coupling, Afferent-Coupling, Efferent-Coupling.

Sources

  • Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.

  • Stevens, Wayne P., Glenford J. Myers, and Larry L. Constantine (1974). “Structured Design.” IBM Systems Journal, Vol. 13, No. 2, pp. 115-139.

    • Original formalization of coupling and cohesion metrics in software engineering
    • Classic paper establishing coupling as fundamental to modular design

  • Constantine, Larry L. (1968). “Coupling and Cohesion.” Structured Design methodology. Historical origin of coupling metrics.

  • Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts. O’Reilly Media. ISBN: 978-1-492-08689-5.

    • Chapter 2: Discerning Coupling in Distributed Architectures

  • Fowler, Martin (2001). “Reducing Coupling.” IEEE Software, July/August 2001. Low coupling between layers, high cohesion within them.

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks