DRY

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” - Pragmatic Programmer (Book)

The simple way to see DRY in terms of duplicated code. See DRY Don't Repeat Yourself In Terms of Code

However, a more important adherence to DRY is in terms of knowledge duplication (avoiding knowledge being dispersed in multiple places). Packaging responsibility into a single place to allow code evolution to happen by changing one place. Without having to adjust the unclear tentacles of fragmented responsibility throughout the code base.

• Code Duplication: Copy-pasting the same implementation in multiple places.
• Knowledge Duplication/Fragmentation: Scattering decision logic across several classes or modules.

While code duplication is often a violation of DRY. A more evolved view of looking at DRY is not simply about code duplication. In fact in some cases exact code duplication could be NOT a violation of DRY, IF the duplicated code represents [different knowledge/different logical functionality] (Eg. Not All Code Duplication Is Knowledge Duplication).

The peskier violation of DRY is harder to spot, and is NOT about code duplication but about unpackaged/uncentralized responsibility. When a change in one class requires non-obvious, corresponding logic changes in other parts of the system, changes the compiler cannot enforce.

In this manner DRY is highly tied to SRP (single-responsibility-principle), in the way that not only a class should have a single reason to change. But that the class should be GREEDY about that reason for change that it claimed, class must NOT share the claimed reason for change with anyone else. It MUST aim to be the ONLY owner of that responsibility for change.

---

Children

1. DRY Don't Repeat Yourself In Terms of Code