Capítulo 13: Cohesión de componentes - Clean Architecture

Como los componentes son un conjunto de clases hay que establecer cómo se agrupan las clases. 

Hay tres principios sobre la cohesión de los componentes:

• REP: The Reuse/Release Equivalence Principle.
• CCP: The Common Closure Principle.
• CRP: The Common Reuse Principle.

REP o «The Reuse/Release Equivalence Principle»

El principio de equivalencia de reuso/liberación o «REP» establece que un componente de software que se quiera reutilizar debe hacerlo a través de un proceso de despliegue y que este despliegue debe tener un número de versión asignado.

El versionado del componente es una estrategia clave a la hora de asegurar la compatibilidad entre los componentes de un sistema. Cuando se crea una nueva versión de un componente los desarrolladores necesitan saber que cambios lleva esta nueva versión del componente y si es compatible con el resto de componentes.

Las clases que forman el componente deben compartir un mismo propósito, deben ser un grupo cohesivo.

The Common Closure Principle o CPP

Este principio establece que un componente no debería tener múltiples razones para cambiar. Es el principio de responsabilidad única o «SRP» aplicado a componentes.

Si existen dos clases y están lo suficientemente unidas como para cambiar juntas entonces estas deberían estar en el mismo componente. De esta manera, cuando se produzca un cambio en los requisitos del sistema el cambio impactará en un número menor de componentes.

Este principio está relacionado con el Open Closed Principle o «OCP». El diseño de las clases debería ser cerrado a los cambios más comunes que se puedan esperar.

El «Common Closure Principle» amplía esta lección de manera que junta en el mismo componente aquellas clases que están cerca de cambiar por el mismo tipo de cambios. De esta manera, cuando se produce un cambio en los requisitos hay una probabilidad elevada de que el cambio impacte en un menor número de componentes.

El principio también está relacionado con el «Single Responsibility Principle» que propone separar métodos diferentes en diferentes clases si estas tienen razones para cambiar. El «Common Closure Principle» propone separar clases en diferentes componentes si tienen más de una razón para el cambio.

La directriz para cumplir el principio sería mantener juntas aquellas clases que cambian en el mismo tiempo y por la misma razón manteniendo separadas las que no lo hacen.

The Common Reuse Principle (CRP)

Este principio establece que las clases y módulos que tienden a reutilizarse juntos pertenecen a un mismo componente.

Es raro que una clase se suela reusar sola. Es más usual encontrar un conjunto de clases que colaboran entre sí. El «Common Reuse Principle» propone que estas clases deberían estar siempre en el mismo componente.

Este principio también nos dice que NO debería ir en un mismo componente. Por ejemplo, si un componente A usa un componente B el componente A crea una dependencia con B. Si el componente A sólo utiliza una clase del componente B, cuando este cambie, el componente A necesita ser recompilado, revalidado y redesplegado.

Si se depende de un componente hay que asegurar que se depende de cada clase de ese componente. Las clases de ese componente deberían ser inseparables.

El diagrama de tensión para la cohesión de componentes

Los tres principios tienden a pelear entre ellos. Mientras que «Reuse/Release Equivalence Principle» y «Common Close Principle» son principios de inclusión y tienden a hacer los componentes más grandes el «Common Reuse Principle» es un principio de exclusión haciendo los componentes más pequeños.

Si un arquitecto se enfoca en aplicar los principios «Reuse/Release Equivalence Principle» y «Common Reuse Principle» (de inclusión), a la hora implementar un cambio en los requisitos, se encontrará con que este cambio tendrá un impacto en muchos componentes.

Si el arquitecto se enfoca en los principios «Reuse/Release Equivalence Principle» y «Common Reuse Principle» provocará muchos despliegues de código innecesarias.

Si el foco está puesto en «Common Reuse Principle» y «Common Close Principle» será más complicado la reutilización del componente.

Un buen arquitecto será capaz de encontrar un posición en el triángulo dependiendo de los aspectos actuales del equipo de desarrollo

Estos aspectos cambiarán a lo largo de la vida de un proyecto. En las fases tempranas el «Common Close Principle» es más importante que el «Reuse/Release Equivalence Principle» dado que la capacidad de desarrollo es más importante que la reutilización.

Los proyectos tienden a empezar sacrificando la reutilización y, a medida que el proyecto madura, los otros dos principios van ganando importancia. Esto significa que la estructura de componentes no es algo fijo y que va evolucionando con el tiempo.

Conclusión

La agrupación de clases en componentes viene dada por la prioridad entre la capacidad de desarrollo y la reusabilidad. Debido a que las necesidades de un proyecto van evolucionando a lo largo del tiempo el equilibro entre los principios va a ir variando. Por esta razón la composición de componentes irá evolucionando de la capacidad de desarrollo a la reusabilidad.