Principios de Componentes
Los componentes para los principios pueden ser vistos como la agrupación de clases u otros artefactos de software que tienen un único propósito dentro de un sistema y que pueden vincularse con otros componentes.
Por otro lado, los principios de componentes son indicaciones de cómo construir y relacionar componentes en una arquitectura. Existen dos tipos de principios: los Principios de Cohesión y los Principios de Acoplamiento, cada uno compuesto por tres principios:
Principios que determinan la asignación de clases u otros artefactos de software en un componente.
El gránulo de la reutilización es el gránulo de la liberación.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Un componente debe estar compuesto por artefactos de software que comparten un propósito y una razón significativa para estar juntos para su publicación.
Reúne en componentes aquellas clases que cambian por las mismas razones y en los mismos momentos. Separa en componentes diferentes aquellas clases que cambian en momentos y por motivos distintos.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Un componente debe tener una estrategia de cierre para reducir al mínimo los cambios posibles frente a un cambio de requisitos.
Este principio es una extensión de SRP, ya que se alinea con la descripción: "Un componente no debe tener múltiples razones para cambiar". Además, se relaciona con OCP, ya que se alinea con la descripción: "Reúne en un mismo componente aquello que esté cerrado a los mismos tipos de cambio".
No obligues a los usuarios de un componente a depender de cosas que no necesitan.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Un componente debe contener artefactos de software que tiendan a ser reutilizados juntos, mientras que aquellos que no estén vinculados estrechamente entre sí no deben formar parte del componente.
Este principio es una extensión de ISP, ya que se alinea con la descripción: "No dependan de componentes que tienen clases o módulos que no necesite".
El siguiente diagrama se creó en base al que se presenta en el libro Clean Architecture: A Craftsman’s Guide to Software Structure and Design (2017) y solo se añadió algunos elementos.
| Diagrama |
|---|
| Este diagrama representa los efectos conflictivos de los 3 principios de cohesión a la hora de estructurar componentes y nos sirve para identificar y equilibrar ciertas preocupaciones arquitectónicas. Por ejemplo, si nos centramos únicamente en los principios de CCP y CRP, el resultado será un componente difícil de reutilizar. También se destaca que seguir los principios de REP y CCP aumentan el tamaño del componente, mientras que seguir el principio de CRP hace lo opuesto. |
 |
Es importante destacar que la estructura de los componentes deben responder a la necesidad actual que esta mas relacionada con la forma en que se desarrolla y utiliza el proyecto que con su funcionalidad real. Por lo tanto, los componentes se ubicarán en diferentes posiciones del diagrama a medida que el sistema de software evolucione y madure con el tiempo.
Principios que definen como se relacionan los componentes.
No permita ciclos en el gráfico de dependencia de componentes.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
La dependencia entre componentes debe estar libre de ciclos, ya sea mediante la creación de un nuevo componente o aplicando la inversión de dependencias para romper los ciclos.
| Violación de ADP | Solución 1: Crear un nuevo componente |
|---|---|
| Podemos observar que existe un ciclo representado por flechas rojas entre los componentes User, Project y Authorization, por lo que supone una violación a este principio. | Para romper este ciclo, se puede crear un nuevo componente en el cual se ubicarían los elementos comunes para Project y Authorization. De esta manera, ambos componentes dependerían del nuevo componente Permissions |
|
|
| Solución 2: Inversión de dependencias |
|---|
| Otra forma de romper este ciclo es recurrir a la inversión de dependencias. Por ejemplo, el componente Project declara los servicios que necesita, como en el caso de Permissions, y el componente Authorization implementa ese servicio. |
|
Dependa en la dirección de la estabilidad.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Cualquier componente volátil no debería depender de otro componente difícil de cambiar, ya que también se volverá complicado cambiarlo.
SDP apunta a la estabilidad, donde un componente se considera estable cuando varios otros componentes dependen de él, mientras que se considera inestable cuando no tiene componentes que lo utilicen.
| Ejemplo: Componente Estable e Inestable |
|---|
 |
SDP cuenta con la fórmula llamada Inestabilidad (I) y establece que la métrica I de un componente debe ser mayor que la métrica I de los componentes de los cuales depende.
| Fórmula | Descripción |
|---|---|
|
I: Inestabilidad Fan-in: Número de clases externas con dependencias entrantes Fan-out: Número de clases internas con dependencias salientes Donde: I : rango [0,1] I = 0 : Componente Máximamente Estable I = 1 : Componente Máximamente Inestable |
| Ejemplo: Calculando la métrica en el componente User |
|---|
| Métrica en Componente User: El valor de Fan-in es 3 El valor de Fan-out es 1 Por lo tanto: Es útil al diagramar ubicar los componentes cambiables (inestables) en la parte superior, como se muestra con los componentes de Presentación y Persistencia, porque si notamos flechas que apuntan hacia arriba, supondrían una violación al SDP y también de ADP. Esto se debe a que los componentes estables no deberían depender de componentes inestables. |
| Violación de SDP |
|---|
| En este caso, el componente Authentication está diseñado para ser fácilmente modificable (inestable) cuando sea necesario. Sin embargo, alguien a cargo del componente User ha establecido una dependencia hacia Authentication, lo cual provoca que cualquier cambio en Authentication tenga un impacto en User y en sus dependientes. Además, si comparamos las métricas de 0.33 para User y de 1 para Authentication, esto indica una violación de SDP |
|
| Solución al problema anterior |
|---|
| Podemos solucionar este problema aplicando la inversión de dependencias, lo que resultaría en la creación de un nuevo componente abstracto llamado GeneralServices. En este componente abstracto, colocamos la abstracción que utilizará User y la que implementará Authentication, de manera que las métricas para cada componente concuerdan. Estos componentes abstractos son una táctica común en lenguajes de tipado estático como C# y Java, pero no existen en lenguajes de tipado dinámico como JavaScript y Python, ya que no lo requieren. |
|
Un componente debe ser tan abstracto como estable.
- Robert C. Martin (Uncle Bob), Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 2017
Un componente estable debe ser abstracto para permitir su extensión a través del uso de interfaces, clases abstractas u otros artefactos abstractos, y está orientado a encapsular políticas de alto nivel. Por otro lado, un componente inestable debe ser concreto e incluir el software volátil que se puede cambiar fácilmente.
Este principio en conjunto con SDP son una extensión de DIP para los componentes.
SAP cuenta con la fórmula Abstracción (A) y su valor representa la proporción de interfaces y clases abstractas en un componente en relación al número total de clases en el componente.
| Fórmula | Descripción |
|---|---|
|
A: Abstracción Na: Número de clases abstractas e interfaces en el componente Nc: Número de clases en total en el componente Donde: A : rango [0,1] A = 0 : Componente Máximamente Concreto A = 1 : Componente Máximamente Abstracto |
| Ejemplo: Calculando la métrica en el componente User |
|---|
| Métrica en Componente User: El valor de Na es 3 El valor de Nc es 6 Por lo tanto: Se puede observar que los componentes User y Publication son tan estables como abstractos. Esta abstracción les permite ser extendidos y además, estos componentes incluyen las políticas de alto nivel. |
El siguiente gráfico está basado al mostrado en el libro Clean Architecture: A Craftsman’s Guide to Software Structure and Design (2017). Nos ayuda a identificar las zonas a las que debemos apuntar (zona verde) y las zonas que debemos evitar (zona roja) al distribuir las métricas mostradas en SDP y SAP de cada componente.
🟥 Zonas de Exclusión: Por lo general, evite que sus componentes se encuentren en la zona de dolor y en la zona de inutilidad.
- Zona de dolor: Los componentes ubicados aquí son difíciles de cambiar y extender. En esta área se pueden encontrar esquemas de bases de datos, bibliotecas de utilidades, entre otros.
- Zona de Inutilidad: Los componentes ubicados aquí son elementos de software sin usar porque son muy abstractos y sin dependientes. En esta área pueden encontrarse interfaces que nunca fueron implementadas.
🟩 La Secuencia Principal: Es la zona más deseable donde se deben ubicar los componentes. Debemos apuntar a los extremos de la secuencia principal (puntos verdes) o cerca de esta (línea verde).
| Ejemplo: Ubicando componentes en el gráfico de Inestabilidad/Abstracción |
|---|
| Es fundamental destacar que este ejemplo es meramente ilustrativo. Para lograr una representación más adecuada, sería necesario incluir muchos más componentes, y dentro de estos componentes, muchos más elementos de software. |
 |
Esta métrica representa cuán alejado está un componente de la Secuencia principal. Si la métrica D de un componente no es cercana a cero, es recomendable revisarlo y, de ser necesario, reestructurarlo.
| Fórmula | Descripción |
|---|---|
|
D: Distancia de la Secuencia Principal A: Métrica SAP I: Métrica SDP Donde: D : rango [0,1] D = 0 : El componente está directamente en la secuencia principal D = 1 : El componente está lo más lejos posible de la secuencia principal |
| Ejemplo: Calculando D en el Componente User |
|---|
| Métrica en Componente User: El valor de A es 0.5 El valor de I es 0.25 Por lo tanto: |
| Ejemplo: Seguimiento del Componente User |
|---|
| Podemos aplicar límites de control al analizar las versiones de un componente y sus métricas de Distancia de la Secuencia Principal. Por ejemplo, imaginemos que el componente User tiene varias versiones, como se muestra en la imagen; en este caso, podemos notar que se sobrepasa el límite de control en la versión 2.2, por lo que sería deseable analizar dicha versión |
 |
Todas las métricas presentadas no son leyes absolutas, son simplemente referencias a tener en cuenta al analizar los componentes de una arquitectura. Asimismo, todos los ejemplos presentados son meramente ilustrativos, ya que deberían incluir muchos más elementos de software.
