Chapter 29. Coupling
To prepare to write their classic text Structured Design, Ed Yourdon and Larry Constantine examined programs to find out what made them so expensive. They noticed that the expensive programs all had one property in common: changing one element required changing other elements. The cheap programs tended to require localized changes.
They dubbed this change infection property “coupling.” Two elements are coupled with respect to a particular change if changing one element necessitates changing the other element.
For example, a calling function is coupled to a called function with respect to changes to the name of the called function:
caller() called() called() // changing this name requires changing the call site(s) too ... // changing the formatting of the body requires no changes to call sites
The second comment here emphasizes an important nuance of coupling: we can’t just say that two elements are coupled. To say something useful, we have to also say coupled with respect to which changes. If two elements are coupled with respect to a change that never happens, then they aren’t coupled in a way that should concern us. That coupling is the boulder at the top of the hill that never rolls down to crush the village.
Analyzing coupling cannot be done simply by looking at the source code of a program. We need to know what changes have happened and/or are likely to happen before we can tell whether two elements are coupled. (For an experiment, see which pairs of ...
Get Tidy First? now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.