Coupling
The degree of interdependence between software modules, with low coupling meaning modules can be understood, changed, and tested independently.
Also known as: Low Coupling, Loose Coupling, Tight Coupling, Module Coupling
Category: Software Development
Tags: software-development, principles, design-patterns, architecture, systems-thinking
Explanation
Coupling measures how much one module depends on and is affected by another. Low (loose) coupling means modules interact through well-defined, narrow interfaces and can be changed independently. High (tight) coupling means modules are deeply intertwined, so changes in one ripple through others.
## Types of Coupling (Worst to Best)
Constantine and Yourdon identified levels from tightest to loosest:
### Content coupling (worst)
One module directly accesses or modifies the internal data of another. Example: reaching into another class's private fields.
### Common coupling
Multiple modules share global data. Example: modules reading and writing the same global variables.
### External coupling
Modules share an externally imposed data format, communication protocol, or device interface.
### Control coupling
One module controls the flow of another by passing control information (flags, commands). Example: passing a boolean that determines which branch of logic to execute.
### Stamp coupling
Modules share a composite data structure but use only parts of it. Example: passing an entire `User` object when only the name is needed.
### Data coupling (best)
Modules communicate through simple, well-defined parameters. Each parameter is necessary, and no unnecessary data is shared.
### Message coupling (ideal)
Modules communicate only through messages or events, with no direct dependency on each other's interfaces.
## Why Low Coupling Matters
- **Independent development**: Teams can work on different modules without coordination overhead
- **Easier testing**: Modules can be tested in isolation with simple mocks or stubs
- **Reduced ripple effects**: Changes to one module don't cascade through the system
- **Better reusability**: Loosely coupled modules can be used in different contexts
- **Simpler reasoning**: You can understand one module without understanding the whole system
## Coupling and Cohesion
Coupling and cohesion are complementary design goals:
| Goal | Within a module | Between modules |
|---|---|---|
| Cohesion | Maximize (related things together) | - |
| Coupling | - | Minimize (unrelated things apart) |
High cohesion naturally leads to low coupling: when a module is focused on one concern, it has fewer reasons to depend on other modules.
## Reducing Coupling
- **Depend on abstractions**: Use interfaces and abstract types rather than concrete implementations (Dependency Inversion Principle)
- **Encapsulate**: Hide internal details behind well-defined public APIs
- **Use events/messages**: Decouple sender and receiver through publish-subscribe patterns
- **Apply the Law of Demeter**: Only talk to your immediate collaborators, not their collaborators
- **Minimize shared state**: Prefer passing data to sharing mutable state
## Beyond Software
Coupling applies to any interconnected system:
- **Organizations**: Tightly coupled teams need constant coordination; loosely coupled teams (microservices, two-pizza teams) move independently
- **Knowledge systems**: Notes linked by topic are loosely coupled; notes that duplicate content are tightly coupled
- **Processes**: Loosely coupled workflows can adapt when one step changes; tightly coupled ones break
Related Concepts
← Back to all concepts