DRY Principle

Introduction

Don't Repeat Yourself (DRY) means every piece of knowledge should have a single authoritative representation. Duplicated validation, fee calculation, or state transition logic diverges over time and breaks interviews when you forget to update one copy.

DRY applies to logic and intent, not character-for-character code. Two similar-looking loops may represent different business rules — forcing abstraction then violates clarity.

Balance DRY with readability — premature extraction creates wrong abstractions.

Understanding the topic

Key concepts

• Single source of truth for business rules.
• Extract shared logic to methods, services, or utilities.
• DRY across layers: constants, validation, mapping.
• Copy-paste is a smell — investigate before abstracting.
• Rule of three: duplicate twice, abstract on third.
• DRY vs WET (Write Everything Twice) trade-off in interviews.

Step-by-step explanation

1. Spot duplicated logic during design walkthrough.
2. Identify the knowledge being repeated (fee formula, eligibility).
3. Extract to well-named method or class.
4. Parameterize differences instead of branching copies.
5. Add test covering extracted unit once.
6. Review new features for re-duplication risk.

Informative example

Centralized fee calculation avoids duplicate hourly math:

public final class FeeRules {
    private FeeRules() {}

    public static Money hourly(Duration stay, Money ratePerHour) {
        long hours = (long) Math.ceil(stay.toMinutes() / 60.0);
        return ratePerHour.multiply(Math.max(1, hours));
    }
}

public final class ParkingTicket {
    public Money fee(Instant entry, Instant exit, Money rate) {
        return FeeRules.hourly(Duration.between(entry, exit), rate);
    }
}

public final class ValetTicket {
    public Money fee(Instant entry, Instant exit, Money rate) {
        return FeeRules.hourly(Duration.between(entry, exit), rate);
    }
}

Both ticket types share FeeRules — change billing policy in one place.

Real-world use

Real-world applications

• Shared validation across create/update flows.
• Common mapping logic in DTO conversions.
• Extracting pricing used by multiple services.

Best practices

• Name abstractions after domain concept, not 'Util'.
• Keep extracted functions pure when possible.
• Do not DRY unrelated coincidental similarity.
• Document why abstraction exists.
• Refactor duplication when touching code anyway.

Common mistakes

• Mega-util class with unrelated static methods.
• Abstracting before second use case (YAGNI).
• DRYing test data until tests unreadable.
• Hidden duplication across microservices via copy-paste APIs.

Advanced interview questions

Summary

DRY targets duplicated knowledge, not just lines. Extract shared business rules once. Wait for clear pattern before abstracting. Avoid god utilities. Keeps LLD maintainable under change.