El principio DRY: No te repitas
DRY hace referencia a uno de los principios de arquitectura de software más importantes: No Te Repitas (ó Don’t Repeat Yourself).
Este principio fue detallado por primera vez en el libro The Pragmatic Programmer por Andy Hunt y Dave Thomas, y como su nombre lo indica, hace referencia a que no debemos duplicar conocimientos dentro del sistema.
Remarco conocimientos porque muchas veces se confunde DRY con “no repetir código” pero eso es solamente una parte del principio DRY. Este principio se extiende a documentación, esquema de base de datos, código y todo lo relacionado al tiempo de vida de un sistema.
«Cada conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.»
The Pragmatic Programmer — Andrew Hunt y David Thomas
Su definición puede sonar algo complicada pero un tip que nos puede ser útil al momento de realizar un cambio en nuestro proyecto es preguntarnos: ¿si hago este cambio, lo tengo que replicar en múltiples lugares y/o formatos? ¿Tengo que cambiar el código y la documentación? ¿Tengo que cambiar el esquema de la base de datos? Si es así, no estamos cumpliendo con DRY.
¿Por qué es importante el principio DRY?
Al repetir comportamientos en el sistema damos lugar a varios problemas de diseño que van a terminar influyendo en la mantenibilidad, reutilización y robustez de nuestro sistema. En cambio, sí velamos por tener presente la aplicación de DRY, desarrollaremos un producto que será significativamente más fácil de mantener y corregir errores, y sin dudas desarrollaremos software con más felicidad y productividad. 😃
Conocimientos adquiridos
El equipo de Orders de Tiendanube (equipo encargado de brindar la mejor experiencia en la gestión de ventas), nos reunimos cada semana para compartir conocimientos y practicar distintos temas sobre el Desarrollo y Diseño de Software. En esta oportunidad queremos compartir nuestra experiencia al tratar el principio DRY.
¿Se rompe DRY por código duplicado?
En este ejemplo tenemos una clase Report con un método encargado de imprimir por pantalla el detalle de ventas de un producto.
Podemos ver que existe código repetido: la forma en la que se formatea el título del reporte y del nombre del producto; el formateo de la fecha; y el cálculo del average.
Pero ¿el código está rompiendo el principio DRY? ¿harías alguna modificación para evitarlo?
Antes de hacer cualquier modificación, pensemos en la definición de DRY: Cada conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.
En este ejemplo vemos una única representación del Cómo debe imprimirse un reporte por pantalla, no existe en otra parte, en otra clase o en otro método. La única representación inequívoca y que sabe cómo imprimir el reporte por pantalla es el método show de la clase Report. Toda refactorización que podamos hacer dentro del método, sería lujo.
¿Y ahora se estaría rompiendo DRY?
Ahora supongamos que necesitamos ser capaces de guardar el mismo reporte en un archivo de texto. Podríamos hacer algo como esto, ¿no?
Tal vez deberíamos pensarlo dos veces ya que estamos haciendo un “copy&paste”, con algunas pequeñas modificaciones, para adaptar el código al requerimiento. Si en algún momento debemos hacer una modificación sobre el reporte, vamos a tener que dedicarle esfuerzo a detectar todos los puntos donde también se esté generando el reporte para aplicar la modificación. No es un diseño robusto.
Aplicando DRY
Si aplicamos DRY al ejemplo anterior, una solución podría ser extraer la generación del reporte a un nuevo método para que sea consumido por los distintos métodos que necesitan disponer el reporte al usuario.
Una clase sin comportamiento puede romper el principio DRY
En este ejemplo tenemos una simple e inofensiva clase Line, sin ningún método con comportamientos. Supongamos que esta clase es utilizada en un mapa interactivo para graficar una línea que traza un vehículo que va desde un casillero A hacia un casillero B.
Cuando utilicemos la clase debemos establecer su inicio, fin y longitud, y a medida que avance el vehículo, estos valores son modificados.
Pero ¿cómo podría esta simple clase estar rompiendo DRY? La respuesta va a ser más evidente al momento de usarla:
Cuando instanciamos la clase establecemos sus propiedades en 1 porque el auto todavía no esta en movimiento.
Luego, supongamos que el automóvil avanza hasta el casillero 10, por lo tanto establecemos el largo de la línea en 11. Por último, el auto avanza 4 casilleros más pero escribimos que el largo de la línea es de 1… no tiene sentido, ¿no? Sin dudas fue un error humano al codificar pero el verdadero error es el diseño de la clase Line.
Con el diseño que hicimos de Line, estamos obligando a la persona que desarrolla a que siempre calcule length cada vez que se modifica end o start. Entonces el CÓMO calcular length está repetido por todo el código haciendo que se rompa el principio DRY.
Aplicando DRY
Para hacer que la clase siga el principio DRY y no provoque la duplicación de conocimiento en el cliente que la use, debemos convertir la propiedad length en una propiedad calculada a través de un método. De esta forma, el cliente siempre utilizará el método sin preocuparse en cómo se calcula el tamaño. Y nosotros como dueños de la clase, tenemos el control total de cómo se calcula el tamaño de la linea, pudiendo modificar la lógica sin afectar a los clientes que usan la clase.
Conclusión
Los ejemplos prácticos nos sirvieron para entender las ventajas de aplicar DRY como así también, las desventajas de no aplicarlo. Y concluimos que es un principio que siempre se debe aplicar, no solo en código sino también en todo el proceso de desarrollo del sistema.
