| name | apply-low-coupling |
| description | Use when assigning responsibilities to classes — especially when a change to one class ripples into many others, classes are hard to test in isolation, or reusing a class requires dragging in unrelated dependencies. |
| source | Craig Larman, "Applying UML and Patterns", 3rd ed., Prentice Hall, 2004 |
| tags | ["grasp","low-coupling","design-principles","oop","responsibility-assignment","developer","testability","maintainability"] |
| related | ["apply-high-cohesion","apply-information-expert","apply-law-of-demeter","apply-composition-over-inheritance","apply-solid-principles"] |
Apply Low Coupling
Assign responsibilities so that classes depend on as few other classes as possible, and only on classes unlikely to change.
Why This Is Best Practice
Adopted by: Foundational principle across all major OOP design frameworks — SOLID (Dependency Inversion), Gang of Four ("program to an interface, not an implementation"), GRASP (Larman, 2004). Endorsed by Google (Engineering Practices), Microsoft (.NET Design Guidelines), and ThoughtWorks Technology Radar. Low coupling is the prerequisite for independent deployment in microservices and for test isolation in unit testing.
Impact: Yamashita & Moonen (ICSM 2012) measured 74 Java projects and found coupling between objects (CBO) to be the strongest predictor of maintainability degradation — high CBO classes required 2–3x more effort to change than low-CBO counterparts. Google's SRE documentation identifies tight coupling as the primary cause of cascading failures in distributed systems. Highly coupled classes cannot be tested without their dependencies, tripling test setup cost.
Coupling is unavoidable — classes must collaborate. The goal is not zero coupling but coupling: depend on abstractions over concretions, on stable elements over volatile ones, on fewer elements over many. The Law of Demeter is a specific coupling rule; Low Coupling is the general principle that motivates it and all structural decoupling techniques.
