100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace

What is the DRY Principle?

Learn the DRY principle in software design — single source of truth, avoiding duplication, and its trade-offs — with a Java example.

easyQ69 of 226 in Object Oriented Programming Est. time: 4 minsLast updated:
Open Code Lab

Expected Interview Answer

DRY, short for "Don’t Repeat Yourself," is the design principle that every piece of knowledge or logic in a system should have a single, unambiguous, authoritative representation, rather than being duplicated in multiple places.

Duplication is dangerous not because typing the same code twice is slow, but because when a business rule changes, every duplicated copy must be found and updated in lock-step, and missing even one creates a silent bug. In object-oriented systems, DRY is achieved through mechanisms like extracting shared logic into a base class, a reusable method, a shared utility, or a well-named constant, so there is exactly one place to change when requirements shift. DRY applies to more than code — it also covers duplicated business rules, duplicated configuration, and duplicated documentation. It should be balanced against premature or incorrect abstraction: forcing two coincidentally similar pieces of code to share an abstraction before their relationship is proven can create worse coupling than the original duplication.

  • A change to a rule only needs to happen in one place
  • Reduces the risk of inconsistent, drifting duplicate logic
  • Makes the codebase smaller and easier to navigate
  • Improves testability by concentrating logic behind one entry point

AI Mentor Explanation

Instead of every batting coach independently writing their own version of the official LBW rule explanation, the academy maintains one authoritative rulebook that every coach references. When the rule is clarified, only the rulebook is updated, and every coach automatically teaches the correct version. That is DRY: one authoritative source of truth for a piece of knowledge, instead of many independently maintained copies that can drift apart.

Step-by-Step Explanation

  1. Step 1

    Spot duplicated knowledge

    Find logic, rules, or values that appear in more than one place in the codebase.

  2. Step 2

    Confirm it is the same concept

    Verify the duplicates represent one true piece of knowledge, not coincidentally similar but unrelated logic.

  3. Step 3

    Extract a single source of truth

    Move the logic into one method, class, or constant that everything else references.

  4. Step 4

    Replace duplicates with references

    Update every duplicated site to call or reference the single authoritative source instead.

What Interviewer Expects

  • A correct statement of DRY: single authoritative representation of each piece of knowledge
  • Understanding that the risk of duplication is inconsistent updates, not just extra typing
  • Awareness that DRY applies to business rules and config, not only code
  • Recognition that premature abstraction to satisfy DRY can be harmful (WET vs over-engineered)

Common Mistakes

  • Believing DRY only means avoiding copy-pasted code snippets
  • Forcing two coincidentally similar but conceptually unrelated pieces of code to share one abstraction
  • Ignoring duplicated business rules or configuration values while focusing only on code
  • Not recognizing that some duplication is an acceptable trade-off versus a fragile shared abstraction

Best Answer (HR Friendly)

DRY means every piece of important knowledge in a system, like a business rule or a formula, should live in exactly one place. If it is duplicated in several places, a future change has to be made everywhere consistently, and it is very easy to miss one spot and introduce a bug. So we extract shared logic into one method or class and have everything else reference that single source.

Code Example

Removing duplication with a shared method
// Violates DRY: the same discount formula duplicated in two places
class OrderServiceBad {
    double totalForRegular(double price, int qty) {
        return price * qty * 0.95; // 5% discount duplicated
    }
    double totalForBulk(double price, int qty) {
        return price * qty * 0.95 * 0.9; // same discount, duplicated again
    }
}

// Follows DRY: one authoritative discount calculation
class OrderServiceGood {
    private double applyStandardDiscount(double amount) {
        return amount * 0.95; // single source of truth for the discount
    }
    double totalForRegular(double price, int qty) {
        return applyStandardDiscount(price * qty);
    }
    double totalForBulk(double price, int qty) {
        return applyStandardDiscount(price * qty) * 0.9;
    }
}

Follow-up Questions

  • How do you decide whether duplication is coincidental or represents true shared knowledge?
  • What is the WET anti-pattern and how does it relate to DRY?
  • How can premature abstraction violate the spirit of good design while technically satisfying DRY?
  • Does DRY apply to test code the same way it applies to production code?

MCQ Practice

1. DRY stands for?

DRY is the acronym for "Don't Repeat Yourself."

2. The core risk DRY protects against is?

The real danger of duplication is that one copy gets updated and another is forgotten, causing inconsistent behavior.

3. Which is a valid caution when applying DRY?

Premature abstraction of coincidentally similar code can create worse coupling than the original duplication.

Flash Cards

DRY in one line?Every piece of knowledge should have one single, authoritative representation in the system.

Main risk of duplication?Updates can be applied inconsistently, causing silent bugs when rules change.

Does DRY only apply to code?No — it also applies to business rules, configuration, and documentation.

A caution when applying DRY?Do not force coincidentally similar, unrelated code into one fragile shared abstraction.

1 / 4

Continue Learning