Why Your Obsession with DRY Principle is Making Your Code Worse

The DRY Principle: A Double-Edged Sword

In the world of software development, the DRY (Don’t Repeat Yourself) principle is often hailed as a golden rule. It advises developers to avoid duplicating code, ensuring that every piece of knowledge has a single, unambiguous, authoritative representation within a system. However, like any principle, it’s not a one-size-fits-all solution. In fact, an overzealous adherence to DRY can sometimes lead to more harm than good.

The Pitfalls of Over-Engineering

Imagine you’re working on a simple task, like calculating the price of products with and without discounts. Without DRY, you might have two separate functions:

function calculatePriceWithPercentageDiscount(price: number, discountPercentage: number): number {
    return price * (1 - discountPercentage / 100);
}

function calculatePriceWithFixedDiscount(price: number, discountAmount: number): number {
    return price - discountAmount;
}

These functions are straightforward and easy to understand. However, in the name of DRY, you might combine them into a single function:

function calculatePrice(price: number, discount: number | { type: 'percentage' | 'fixed', value: number }): number {
    if (typeof discount === 'number') {
        return price - discount;
    } else if (discount.type === 'percentage') {
        return price * (1 - discount.value / 100);
    } else {
        throw new Error('Invalid discount type');
    }
}

At first glance, this seems like a good idea, but it introduces unnecessary complexity. The combined function is harder to read and use correctly, especially for developers who are not familiar with the nuances of the discount parameter[1].

Readability and Simplicity

One of the most significant drawbacks of strict DRY adherence is the loss of readability and simplicity. When you try too hard to avoid repeating code, you can end up with convoluted solutions that are difficult to maintain.

For example, consider a scenario where you need to calculate the age of users based on their birth year. Without DRY, you might have separate functions for different user roles:

function calculateStudentAge(birthYear: number): number {
    return new Date().getFullYear() - birthYear;
}

function calculateTeacherAge(birthYear: number): number {
    return new Date().getFullYear() - birthYear;
}

While these functions are identical, they are clear and easy to understand in their respective contexts. Combining them into a single function with additional parameters or conditional logic would only add complexity without any real benefit[1].

Premature Abstraction

Premature abstraction is another trap that developers fall into when they adhere too strictly to the DRY principle. This occurs when you try to make your code reusable and general before you fully understand the requirements or future needs of your application.

Here’s an example of how premature abstraction can lead to unnecessary complexity:

In this example, creating an abstract PizzaOrderer class and subclasses for different pizza types might seem like a good way to avoid code duplication. However, it introduces unnecessary complexity and coupling between different parts of the system. If the requirements change, such as needing to support half-Hawaiian, half-pepperoni pizzas, this abstraction can become a hindrance rather than a help[5].

Coupling and Flexibility

Strict adherence to DRY can also lead to increased coupling between different parts of your system. When you eliminate repeated code by creating shared functions or classes, you might inadvertently make unrelated sections of your application depend on each other.

For instance, consider two different applications that have similar but not identical controllers. If you create an abstract class to group the common logic, you might end up with a situation where changing the abstract class affects both applications, even if they are supposed to evolve differently in the future[3].

The Cost of Wrong Abstractions

The phrase “duplication is far cheaper than the wrong abstraction” is a wise one. Wrong abstractions can lead to code that is rigid and difficult to change. Here’s an example of how this can play out:

// Wrong Abstraction
class ProductController {
    private discountType: 'percentage' | 'fixed';

    constructor(discountType: 'percentage' | 'fixed') {
        this.discountType = discountType;
    }

    calculatePrice(price: number, discount: number): number {
        if (this.discountType === 'percentage') {
            return price * (1 - discount / 100);
        } else {
            return price - discount;
        }
    }
}

// Usage
const percentageController = new ProductController('percentage');
const fixedController = new ProductController('fixed');

console.log(percentageController.calculatePrice(100, 20)); // 80
console.log(fixedController.calculatePrice(100, 20)); // 80

In this example, the ProductController class is designed to handle both percentage and fixed discounts. However, this abstraction is inflexible and can become cumbersome if the discount logic changes or if new types of discounts are introduced[3].

Practical Advice

So, how do you balance the benefits of DRY with the need for simplicity, readability, and flexibility?

1. Code for the Specific First: Before generalizing, ensure that the code works for the specific use case. Only refactor and generalize when the need arises and the benefits are clear[3].

2. Avoid Premature Abstraction: Do not create abstractions unless they are clearly necessary. Premature abstraction can lead to unnecessary complexity and coupling[3].

3. Consider the Context: DRY is about avoiding the duplication of knowledge, not just any code. Ensure that the code you are duplicating is indeed a piece of knowledge that should not be repeated[3].

4. Readability Over Reusability: Sometimes, readability and simplicity are more important than reusability. If repeating code makes it easier to understand and maintain, it might be the better choice[1].

5. Refactor Judiciously: Refactor code only when it is necessary and when the benefits outweigh the costs. Avoid knee-jerk reactions to code duplication[5].

Conclusion

The DRY principle is a valuable tool in the developer’s toolkit, but it should not be applied blindly. By balancing the need to avoid code duplication with the importance of readability, simplicity, and flexibility, you can write code that is both maintainable and efficient.

Remember, the goal of software development is not just to write code that works, but to write code that is easy to understand, maintain, and evolve over time. So, the next time you’re tempted to apply DRY at all costs, take a step back and ask yourself: “Is this really making my code better?”