DRY – Don’t Repeat Yourself
Every piece of knowledge should have a single, authoritative representation.
The violation
The VAT rule copy-pasted into every document that mentions money:
class CustomerReceipt {
BigDecimal total(...) { return net.multiply(new BigDecimal("1.20")); }
}
class SupplierInvoice {
BigDecimal total(...) { return net.multiply(new BigDecimal("1.20")); }
}
class RefundNote {
BigDecimal total(...) { return net.multiply(new BigDecimal("1.175")); } // <- the old rate.
} // Nobody noticed.
When the rate changed, two copies were updated and one wasn’t. Now refunds disagree with receipts, and the bug is invisible until an auditor finds it. That’s the real cost of duplication: not the extra lines, but the fact that a single piece of knowledge can now be wrong in some places and right in others.
The fix
Vat is the one authoritative home of the VAT rule.
CustomerReceipt and SupplierInvoice consume it
and contain no tax knowledge of their own – they cannot drift apart.
Benefits
- One change, everywhere correct – a rate change is one edit, and every document agrees.
- No silent divergence – the copy-that-didn’t-get-updated bug class is structurally impossible.
- The knowledge is findable – “how do we apply VAT?” has exactly one answer, with one test.
The overuse warning
DRY is about knowledge, not textual similarity. Two code fragments that look the same but represent different decisions – say, the customer discount cap and the staff discount cap both being 10% this quarter – should stay separate: merging them couples rules that will change for different reasons, and someone editing “the shared constant” changes both without knowing. A useful heuristic is the rule of three: tolerate a second occurrence, extract on the third, when the shape of the real abstraction is visible. See Use with judgement.