El principio DRY (Don’t Repeat Yourself) dice que cada pieza de conocimiento del sistema debe tener una única representación clara dentro del código.
Dicho en cristiano: si una regla cambia, deberíamos tocarla en un solo sitio. Si tenemos la misma validación, cálculo o consulta repetida en cinco sitios, el día que cambie una condición tendremos que acordarnos de los cinco. Y ya sabes cómo acaba eso.
DRY no significa “no repetir jamás dos líneas parecidas”. Significa no duplicar conocimiento. Esta diferencia parece pequeña, pero evita muchas abstracciones absurdas.
El problema de repetir conocimiento
Supongamos que tenemos una regla de negocio sencilla: los pedidos de más de 100 euros tienen envío gratis.
Si esa regla aparece repetida por toda la aplicación, tenemos un problema:
if (pedido.Total > 100)
{
costeEnvio = 0;
}Y luego en otro sitio:
bool tieneEnvioGratis = carrito.Total > 100;Y más adelante:
return totalCompra > 100 ? "Envio gratis" : "Envio normal";El código parece inocente, pero la regla está duplicada. Si mañana marketing decide que el envío gratis empieza en 120 euros, tenemos que encontrar todas las copias.
Y si se nos olvida una, la aplicación empieza a comportarse de forma distinta según la pantalla. Una maravilla, vamos.
Aplicando DRY
La solución consiste en expresar esa regla una sola vez, con un nombre que explique su intención.
public class PoliticaEnvio
{
private const decimal ImporteMinimoEnvioGratis = 100m;
public bool TieneEnvioGratis(decimal total)
{
return total >= ImporteMinimoEnvioGratis;
}
}Ahora el resto del código no necesita saber el número mágico. Solo pregunta:
if (politicaEnvio.TieneEnvioGratis(pedido.Total))
{
costeEnvio = 0;
}Esto es mucho mejor porque la regla vive en un único sitio. Cambiarla es fácil, probarla es fácil, y leer el código también es más fácil.
DRY no es hacer una abstracción por todo
Esta es la parte importante. DRY no significa que cada vez que veas dos líneas parecidas tengas que crear una clase, una interfaz, tres genéricos y un patrón Factory porque te has venido arriba.
Dos fragmentos de código pueden parecer iguales y, sin embargo, representar conceptos distintos.
Por ejemplo:
decimal descuentoCliente = total * 0.10m;
decimal ivaProducto = total * 0.21m;Ambas líneas multiplican por un porcentaje. Pero una habla de descuentos y otra habla de impuestos. Si las metemos en una abstracción común demasiado pronto, igual hemos creado una dependencia artificial entre dos cosas que deberían evolucionar separadas.
La duplicación accidental se corrige. La similitud casual se tolera.
Si no tienes claro que dos piezas de código cambian por el mismo motivo, espera un poco antes de abstraer.
DRY y los patrones de diseño
Los patrones de diseño muchas veces ayudan a aplicar DRY, porque nos permiten aislar una variación en una parte concreta del sistema.
Por ejemplo:
- Con
Strategy, evitamos repetir algoritmos parecidos repartidos enswitch. - Con
Factory, concentramos la lógica de creación. - Con
Template Method, dejamos común el esqueleto de un algoritmo y movemos los pasos variables. - Con
Repository, evitamos repetir consultas y detalles de persistencia por toda la aplicación.
La idea no es “usar patrones porque sí”. La idea es que, cuando detectamos una responsabilidad repetida, la colocamos donde tenga sentido.
Cuándo merece la pena
DRY merece la pena especialmente cuando la repetición afecta a:
- Reglas de negocio, porque cambian y suelen tener consecuencias.
- Validaciones, porque si divergen generan errores raros.
- Consultas o acceso a datos, porque duplican detalles técnicos.
- Configuración, porque los valores mágicos desperdigados son una bomba de relojería.
- Algoritmos, porque corregir un bug en una copia y olvidarse de otra es muy habitual.
En cambio, no pasa nada por repetir un poco de código si eso hace que dos módulos queden más claros e independientes.
Una buena pista: si al cambiar una regla tienes que usar el buscador del IDE con miedo, probablemente hay duplicación de conocimiento.
DRY es uno de esos principios sencillos que parecen obvios, hasta que una aplicación crece y descubrimos que la misma regla está escondida en veinte sitios.
Aplicarlo bien consiste en eliminar duplicación real, no en fabricar abstracciones por deporte. Cuando una idea pertenece a un único lugar, el código se vuelve más fácil de mantener, más fácil de probar y bastante menos propenso a dar sustos.
