Loose coupling is a design property in which classes depend little on one another’s implementations. The less one class knows about another class’s internal details, the less likely changes will spread between them. section 4.2.2 section 2.3.2
A practical route to loose coupling is delegation. Keep the requester focused on its own responsibility and move specialized work to a cohesive delegate. The requester calls the delegate’s public operation without knowing how that operation is implemented. section 2.3.2 section 2.4
Catalogue delegates book matching
A Catalogue stores Books and accepts Attributes objects, but does not maintain or inspect the individual book attributes itself. During a search, Catalogue asks each Attributes object whether it matches the target. Attributes knows how matching works, while Catalogue does not need to change when that implementation changes. The same separation leaves Attributes unaware that its objects are stored by Books or Catalogue. section 2.3.2 section 4.2.2
Recognize loose coupling by checking whether:
- A class exposes a small public dependency rather than relying on another class’s private representation. section 2.3.2
- A class avoids hardcoding the storage or behavior of collaborators; TeamReport becomes coupled when it must iterate differently through arrays, vectors, and maps. section 11.1.2
- A design can add, remove, or replace algorithms or subscribers without modifying the client or publisher. section 11.4 section 12.2
- Calls follow the Law of Demeter: use objects you aggregate, receive as arguments, or create, rather than reaching through returned objects. section 5.6
