A module should not interact with too many other modules. Furthermore if a module A interacts with another module B, this interaction should be loose, which means that A should not make too many assumptions about B.
If a module A interacts with a module B, there is a certain dependency between these modules. When for example A uses a certain functionality of B, then A depends on B. A makes the assumption that B provides a certain service, and moreover it makes assumptions on how this service can be used (by which mechanism, which parameters, etc.). If one of these assumptions is not true anymore because B has changed for some reason, A also has to change. So the fewer dependencies there are, the less likely it is that A stops working and has to be changed.
Furthermore A makes many and detailed assumptions about B, there is also a high probability that A has to change despite only relying one one other module. This is because in such a case A also needs to change when only a certain detail of B changes.
But if coupling is low, there are only few assumptions between the modules which can be violated. This reduces the chance of ripple effects.
|Principles In "The Pragmatic Programmer"|
|Don't Repeat Yourself||Make It Easy To Reuse||Eliminate Effects Between Unrelated Things||Program Close To The Problem Domain||Keep Knowledge in Plain Text||Write Code That Writes Code|
|Crash Early||Use Assertions to Prevent the Impossible||Use Exceptions for Exceptional Problems||Finish What You Start||Minimize Coupling Between Modules||Configure, Don't Integrate|
|Put Abstractions In Code, Details In Metadata||Always Design for Concurrency||Separate Views From Models||Abstractions Live Longer than Details|