If three classes all validate email addresses in the same way, create a shared validation method. That way, if email validation rules change, you update the one method.
Sometimes the simplest solution is to duplicate code in two places rather than build an abstraction. The key is whether the logic is conceptually the same, not just textually similar.
DAMP (Descriptive And Meaningful Phrases) is often raised, especially in unit tests. DRY ensures every concept in the system has a single authoritative representation in the code. In tests, duplication comes about because they’re testing the same thing, only with slightly different input values or setup code. That the duplication is in the same test fixture/file poses less risk than duplication across files. Furthermore, you don’t want to have to mentally put together a bunch of pieces for you to make sense of the test.
- Design Principles | Hello Interview Low Level Design. www.hellointerview.com . Accessed Sep 10, 2026.
- What does “DAMP not DRY” mean when talking about unit tests? - Stack Overflow. stackoverflow.com . Accessed Sep 11, 2026.
While working on a microservices-based chat application, I wanted to the ability to serialize and de-serialize
Messageobjects between micro-services. Different services had slightly different needs for what to serialize, e.g., text-onlyMessages,Messages with attachments, system-generatedMessages, etc.The tech lead was against a shared serialization/deserialization contract, insisting that duplication was the solution. A shared contract brought about more coupling between microservices that are meant to be deployed independently. With duplicated contracts, and \(N\) micro-services, a given contract needed to be consistent/back-compatible between the 2 micro-services that used it. With a shared contract design, the contracts needed to be consistent/back-compatible between \( N \choose 2 \) pairs!