La reusabilidad en el diseño de software es la práctica de construir código que puedes volver a usar para reducir costos, acelerar lanzamientos y liberar recursos. Si programas en cualquier lenguaje y quieres entender cuándo reutilizar ayuda y cuándo complica, esto es para ti.
La idea central es sencilla: ¿por qué reinventar la rueda si ya existen cosas que funcionan, están validadas y la comunidad confía en ellas? Pero reutilizar bien tiene su truco, y aquí viene lo interesante.
¿Por qué conviene reutilizar código en el desarrollo de software?
Reutilizar no es solo escribir menos líneas. Tiene repercusiones directas en el negocio [00:14].
- Reduce costos y tiempos para lanzar un producto.
- Libera recursos para tareas cruciales como el marketing.
- Evita el trabajo de construir desde cero algo que ya está probado y testeado.
Fíjate en el detalle económico: si desarrollas de forma más sencilla reutilizando componentes, ese dinero que tenías reservado para el desarrollo lo puedes destinar a publicitar el producto [00:40]. La reusabilidad deja de ser un tema técnico y pasa a ser una decisión estratégica.
¿Qué beneficio tiene reutilizar código? Reduce costos y tiempos de desarrollo, y libera presupuesto para otras áreas como marketing, porque aprovechas componentes ya validados en lugar de construirlos desde cero.
¿Qué es DRY y cuándo la reusabilidad se vuelve un problema?
El principio Don't Repeat Yourself (DRY) propone que si algo se repite más de una vez, crees una abstracción que trabaje con esos elementos [01:30]. Suena ideal, pero no todo debe abstraerse.
El riesgo real es que el código se vuelva innecesariamente complejo. Imagina crear la abstracción de la abstracción de la abstracción: para modificar una sola cosa terminas tocando muchísimo [02:00]. Quizás no sea lo mejor.
La recomendación aquí es clara: apela a la sencillez y a lo que funciona. Hay riesgos que es mejor no correr.
¿Siempre debo aplicar DRY? No. Aunque DRY evita duplicación, algunas partes no deberían abstraerse. Si abstraes de más, el código se vuelve difícil de modificar y mantener.
¿Cuáles son los tres niveles de reusabilidad según Erich Gamma?
Erich Gamma, uno de los precursores en el estudio de los patrones de diseño, define tres niveles de reusabilidad [02:20]. Para entenderlos, usemos una analogía con la lasaña.
Clases y funciones: los ingredientes
El primer nivel son las clases o funciones, según el paradigma que uses. Son los ingredientes, los elementos más pequeños de la reusabilidad [02:50]. Recuerda la regla de oro: hacen una sola cosa, pero la hacen bien. Aquí puedes usar JavaScript, Python, Elixir, Ruby, Go o Rust, como gustes.
Patrones de diseño: la receta de cocina
El segundo nivel son los patrones de diseño, que funcionan como una receta [03:20]. Te indican cómo preparar la lasaña, cómo usar los ingredientes y de qué forma se conectan esas funciones. Y como en toda receta, puedes jugar: donde te dicen ocho tomates, puedes usar siete o nueve. Los patrones admiten variación.
Frameworks: la lasaña congelada
El tercer nivel son los frameworks, la lasaña congelada lista para usar [03:50]. Django, Next.js o Rails son herramientas que favorecen la convención sobre la configuración. Rails ya tiene una forma de definir rutas, controladores, modelos y la relación con la base de datos. Next ya sabe manejar rutas y peticiones. No necesitas volver a construir la rueda: eliges la convención que más te guste.
¿Cómo aplicar reusabilidad con un ejemplo de código y abstracciones?
El profesor muestra una clase llamada servicio de usuario con dos elementos clave [05:00].
- Un atributo
URL, que indica la ruta a la que se piden recursos.
- Un método que hace la petición usando esa URL mediante un módulo
HTTP, por ejemplo Axios.
El problema aparece en la dependencia: el servicio de usuario depende del módulo [05:40]. Si algo cambia en el módulo, tienes que cambiar tu clase. Y si tienes 15 servicios que usan ese módulo directamente, un cambio te obliga a modificar los 15.
Aquí entra la abstracción llamada HTTP gateway [06:10]. En lugar de que cada servicio use el módulo directamente, el gateway es quien lo utiliza. El resultado es poderoso: si el módulo cambia, solo modificas un archivo, el gateway, y listo.
¿Qué es una abstracción como HTTP gateway? Es una capa intermedia entre tus servicios y un módulo externo como Axios. Si el módulo cambia, solo modificas el gateway en vez de cada servicio que lo usa.
La nueva cadena de dependencias queda así: el servicio de usuario depende del gateway, y el gateway depende del módulo. Tiene todo el sentido. La pregunta que debes interiorizar es: ¿qué cambiará con más frecuencia, el módulo externo o tu propia abstracción? Esa respuesta guía tu decisión de diseño.
No hay buenas ni malas prácticas absolutas. Hay que definir cuál es la decisión de diseño que más conviene para cada caso.
¿Has utilizado Don't Repeat Yourself al construir tu código? ¿Crees que existe un nivel en el que la reusabilidad se vuelve perjudicial? Cuéntame tu experiencia en los comentarios.
