Cuando la reutilización se vuelve contra la arquitectura

En el mundo del desarrollo solemos sentir pavor ante un fragmento de código repetido. Como defensores del código limpio, corremos a refactorizar esa aberración unificando toda la lógica en un único método de utilidad o clase. Así, conseguimos algo más reusable, reducimos el impacto del mantenimiento y nos sentimos genial.

Pues bien, esta misma idea se suele trasladar a los objetos que traspasan los límites de nuestra arquitectura. Ante la creación de un nuevo objeto, es muy común sentir la tentación de buscar el objeto coincidente en las entrañas de nuestro proyecto, a fin de alcanzar la tan adorada reutilización. El problema de esto es que muchas veces buscamos reutilización y encontramos acoplamiento.

Si has sido cuidadoso a la hora de gestionar tu capa de presentación con algún patrón arquitectónico (recuerda que en artículos anteriores he hablado de MVP y Clean), seguro que te interesa que tus módulos o features puedan evolucionar de forma independiente, y que su mantenimiento no termine por impactar en otras partes del proyecto. Es muy común encontrarse en esta tesitura cuando, por ejemplo, creamos modelos para la Vista. Estos modelos son creados para satisfacer unas necesidades concretas y no deberían considerarse por los otros módulos como «reutilizables» a la ligera. Ante la duda, siempre deberíamos preguntarnos lo siguiente: ¿Tienen diferentes motivos para cambiar? ¿Pueden evolucionar de diferente manera?, y si la respuesta es SÍ, nos conviene crear un objeto nuevo. Aunque en ese momento los campos sean idénticos, es posible que en un futuro cambien y no afecten por igual a ambos módulos.

Reutilización

Para poder trabajar de forma aislada e independiente en varias features a la vez debemos prestar especial atención a las dependencias de nuestros módulos, recordando siempre que, desde el punto de vista de la arquitectura, la duplicidad de un objeto no se marca necesariamente por la igualdad de sus atributos.

*Esta rápida reflexión surge tras la lectura de Clean Architecture: A Craftsman’s Guide to Software Structure and Design, de Robert C. Martin. Libro que recomiendo mucho si os apetece darle una vuelta a esto de los límites y las capas. 😉