Coupling
- •
What it is
- •
a measure of the degree of interdependence or interaction between two modules
- •
- •
Goal
- •
keep coupling as low as possible — low coupling means modules can be developed, tested, and maintained independently
- •
- •
Types (best/loosest to worst/tightest)
- •
data coupling — modules only exchange the primitive data actually needed (e.g.
hitungTotal(harga, jumlah)); no dependency on another module's internal structure - •
stamp coupling — a whole data structure/object is passed even though only part of it is used (e.g. passing a full
mahasiswaobject just to printmahasiswa.nama); makes the structure hard to change since many callers depend on it - •
control coupling — one module passes a flag that dictates another module's internal logic/branching (e.g. a
tipeparameter selecting "admin" vs "user" menu logic); the caller ends up needing to know the callee's internals, violating encapsulation - •
external coupling — a module depends on an external resource (a file, a port, an API); fragile (breaks if the file moves or changes) and hard to test automatically; mitigated by injecting the resource rather than hardcoding it (e.g. passing a
sourcereader instead of opening a fixed file path) - •
common coupling — multiple modules share global/mutable state; a change in one module can silently break another, and bugs are hard to trace
- •
content coupling (worst case) — one module directly reaches into and modifies another module's internal/private data; a severe encapsulation violation
- •
- •
Impact
- •
as coupling increases, complexity of implementation, testing, and maintenance also increases
- •
- •
- •
- •