El principio DRY (Don't Repeat Yourself) en C# te invita a evitar la duplicación de código y a reutilizar rutinas mediante funciones o métodos. Aplicarlo mejora la legibilidad, reduce errores y facilita el mantenimiento de tus proyectos, especialmente cuando trabajas con buenas prácticas de programación orientada a objetos.

¿Por qué se rompe tan seguido el principio DRY?

La razón más común es simple: copiamos y pegamos código todo el tiempo para avanzar más rápido. Y ojo, copiar y pegar no está mal por sí mismo. Lo hacemos cuando buscamos soluciones en Stack Overflow, en blogs o en documentación.

El problema aparece cuando pegas el código sin entenderlo y sin adaptarlo a tu proyecto. Ahí es cuando empiezan a aparecer fragmentos duplicados que después nadie quiere tocar por miedo a romper algo.

¿Qué significa DRY en programación? Don't Repeat Yourself. Es un principio que pide reutilizar rutinas de código en lugar de duplicarlas, normalmente extrayéndolas en funciones o métodos reutilizables.

¿Cuáles son las dos formas en que se duplica el código?

No toda duplicación se ve igual. En la práctica te vas a topar con dos escenarios distintos, y cada uno se resuelve diferente [01:30].

• Código exactamente duplicado: secciones idénticas que puedes extraer tal cual en una función y reutilizar.
• Código muy parecido pero separado: rutinas similares con pequeñas variaciones. Aquí la solución es crear un método común que reciba parámetros para cambiar su comportamiento.

En el segundo caso, en lugar de mantener tres o cuatro funciones casi iguales, terminas con una sola que cubre todos los casos según los parámetros que le pases.

¿Cómo aplicar DRY en un proyecto de C#?

En el ejemplo del proyecto, hay un menú con la opción remove que muestra el mensaje "Ingrese el número de la tarea a remover" y después lista todas las tareas. Esa lógica de listar las tareas también existe en el método ShowMenuTaskList, que valida si la colección es nula o vacía y luego imprime cada tarea con su número y una línea de guiones como separador [03:20].

¿El resultado? La misma rutina escrita dos veces.

¿Cómo identificar el código repetido?

Lee tu código buscando bloques que hagan exactamente lo mismo. En este caso, el ciclo que recorre la lista de tareas, imprime el número y agrega los guiones aparece tanto en el método de listar como dentro del flujo de remover.

Cuando detectes ese patrón, pregúntate: ¿puedo invocar un método existente en lugar de reescribir esto?

¿Cómo refactorizar usando un método existente?

La primera solución fue eliminar el bloque duplicado dentro de remove y simplemente invocar ShowMenuTaskList() en su lugar. Con eso lograste dos cosas:

• Reutilizar código sin tener que copiar la lógica.
• Mejorar la legibilidad, porque al leer el método de remover ya no tienes que analizar un ciclo, ves directamente que se está mostrando la lista de elementos.

Después de aplicar el cambio, basta con correr dotnet build y dotnet run, agregar una tarea como "Terminar de limpiar la casa", entrar a la opción remove y confirmar que el flujo sigue funcionando: aparece el mensaje, se lista la tarea, eliges el número uno y se elimina correctamente [05:40].

¿Qué reto puedes resolver con el principio DRY?

El reto consiste en ir un paso más allá: en vez de invocar ShowMenuTaskList, que tiene la palabra menu en su nombre, extrae solo la porción de código que recorre e imprime las tareas en una función nueva con un nombre más genérico.

Después, invoca esa nueva función en dos lugares:

1. Dentro de ShowMenuTaskList, reemplazando el ciclo actual.
2. Dentro de la opción remove, donde se listan las tareas antes de pedir el número a eliminar.

Así desacoplas la lógica de impresión de la lógica del menú, y dejas un método reutilizable en cualquier parte del proyecto.

¿Está mal copiar y pegar código? No, es una práctica común y útil. El problema es no entender lo que copias ni adaptarlo. Si terminas con bloques duplicados sin refactorizar, ahí sí estás violando DRY.

¿Ya identificaste qué partes de tu propio proyecto en C# están repitiendo lógica? Cuéntame en los comentarios cómo las refactorizaste y qué nombre le pusiste a tu nueva función.