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 note was researched and drafted with AI. How these notes are written →

Graph View

Backlinks