Tight coupling occurs when production-code components depend strongly on one another, making them difficult to test separately. Testability is a useful negative indicator: hard-to-test code often signals insufficient decoupling, but easy testing does not prove good design. section 1.2
Loose coupling is not created merely by inserting interfaces. An interface with one implementation is neither a genuine abstraction nor meaningfully looser than its concrete class; genuine abstractions are discovered when at least two implementations exist. section 8.4
Use coupling as a design warning rather than a guarantee:
- Treat difficult unit testing as evidence to investigate design quality. section 1.2
- Avoid class-interface pairs created only for a database or message bus with one implementation. section 8.4
- Introduce abstractions when multiple implementations establish a real variation, not merely to anticipate future functionality. section 8.4
A misleading abstraction
IMessageBus paired with MessageBus and IUserRepository paired with UserRepository illustrate interfaces that add names without necessarily reducing coupling. A controller depending on Database and IMessageBus shows dependencies that should be judged by their actual separability, not by interface usage alone.
