Principio DRY: No te repitas

DRY_Principle

En el desarrollo de software, hay pocas reglas tan simples y tan poderosas como el principio DRY — Don’t Repeat Yourself.
Aunque parece obvio, romperlo es una de las causas más comunes de bugs, mantenimiento costoso y código difícil de escalar.

¿Qué es el principio DRY?

Definición clásica:
“Cada pieza de conocimiento debe tener una única, inequívoca representación dentro de un sistema.”
— The Pragmatic Programmer (Andy Hunt y Dave Thomas)

En otras palabras: si repites código o lógica, estás creando múltiples fuentes de verdad.
Cuando algo cambie (y eventualmente cambiará), deberás modificarlo en varios lugares, aumentando el riesgo de errores.

Ejemplo clásico de violación de DRY

Supongamos que tenemos una aplicación que calcula el precio final de un producto con impuesto:

public class ProductService
{
    public decimal GetFinalPrice(decimal price)
    {
        decimal tax = price * 0.13m; // IVA del 13%
        return price + tax;
    }
}

public class InvoiceService
{
    public decimal GetInvoiceTotal(decimal subtotal)
    {
        decimal tax = subtotal * 0.13m; // ¡Código repetido!
        return subtotal + tax;
    }
}

Aquí el cálculo del impuesto se repite en dos lugares distintos.
Si el IVA cambia, deberás actualizarlo manualmente en ambos métodos. Si olvidas uno… desastre.

Aplicando DRY correctamente

Podemos centralizar la lógica común en un único lugar, por ejemplo, un servicio de impuestos:

public static class TaxService
{
    private const decimal TaxRate = 0.13m;

    public static decimal CalculateTax(decimal amount) => amount * TaxRate;
}

Y luego usarlo:

public class ProductService
{
    public decimal GetFinalPrice(decimal price)
    {
        return price + TaxService.CalculateTax(price);
    }
}

public class InvoiceService
{
    public decimal GetInvoiceTotal(decimal subtotal)
    {
        return subtotal + TaxService.CalculateTax(subtotal);
    }
}

De esta forma, si cambia el IVA, lo actualizas en un solo lugar y todo el sistema se mantiene coherente.

DRY ≠ Reutilizar por reutilizar

No se trata de eliminar cualquier repetición de texto.
Aplicar DRY en exceso o sin criterio puede generar código confuso o sobreabstracto.

Ejemplo de mala aplicación de DRY:

// Intento forzado de reutilización
public static class MathUtils
{
    public static decimal Calculate(decimal value, decimal percentage)
        => value * percentage;
}

Ahora todos los cálculos de impuestos, descuentos o comisiones se vuelven ambiguos, y perdemos legibilidad.

💬 Consejo: aplica DRY cuando la lógica compartida tenga el mismo significado y propósito.
Si son cosas distintas que se parecen, no las mezcles.

DRY y otros principios relacionados

SRP (Single Responsibility Principle): cada clase debe tener una sola razón de cambio.
KISS (Keep It Simple, Stupid): mantén el código simple, incluso al aplicar DRY.
YAGNI (You Aren’t Gonna Need It): no generalices antes de necesitarlo.

Estos principios se complementan y ayudan a mantener un código limpio, coherente y fácil de mantener.

En resumen

| Error común | Solución DRY | |--------------|---------------| | Copiar y pegar la misma lógica | Centralizar en un método reutilizable | | Repetir estructuras de datos similares | Crear una clase o modelo compartido | | Escribir las mismas validaciones | Implementar helpers o middleware | | Repetir configuración | Usar constantes o archivos de configuración |

Conclusión

El principio DRY es sencillo de entender, pero difícil de aplicar con disciplina.
Adoptarlo desde el inicio te ayudará a evitar inconsistencias, reducir errores y mantener tu base de código viva por más tiempo.

principio-dry:-no-te-repitas