Arquitectura de Software II: Acoplamiento y Cohesión

Tabla de contenido

Introducción

Cuando un componente o módulo depende fuertemente de otro, se dice que están altamente acoplados. Para que nuestros módulos sean fácilmente integrables con otros, es fundamental buscar un bajo acoplamiento.

Acoplamiento

El acoplamiento describe el grado de dependencia entre módulos. Un acoplamiento fuerte puede dificultar el mantenimiento y la evolución del software, mientras que un acoplamiento débil promueve la reutilización y la independencia.

Evaluación del Acoplamiento

Para evaluar el acoplamiento, debemos considerar tanto la cantidad de conexiones como la complejidad de estas interacciones. Un bajo acoplamiento implica que los módulos son independientes y flexibles, facilitando la implementación y los cambios. Esto significa que si las reglas de negocio requieren reemplazar o modificar componentes, el impacto será mínimo.

Aunque el acoplamiento se refiere a las interacciones externas entre módulos, el concepto de cohesión se enfoca en el comportamiento interno de un componente. La cohesión mide qué tan bien definido está el propósito y la responsabilidad de un componente.

Acoplamiento Fuerte (indeseable)

1. Acoplamiento por contenido: Un módulo puede acceder directamente a los datos u operaciones internas de otro.
2. Acoplamiento común: Dos o más módulos dependen de información compartida.
3. Acoplamiento externo: Dependencia de contratos/interfaces, formatos o protocolos impuestos externamente, donde puede generarse un alto impacto a los módulos cuando las dependecias externas cambian.
4. Acoplamiento de control: Un módulo controla los pasos lógicos de otro, indicándole qué hacer o en qué orden.
5. Acoplamiento por estructura de datos: Dos módulos dependen de la misma estructura de datos.
6. Acoplamiento por datos internos: Un módulo depende de detalles internos de otro, los cuáles no están destinados a ser públicos.

Acoplamiento Débil (deseable)

1. Acoplamiento por parámetros: Los módulos se comunican pasando solo los datos necesarios.
2. Acoplamiento por mensaje: Comunicación basada en el envío de mensajes sin exponer implementación interna.
3. Acoplamiento por coincidencia de tipo: Los módulos comparten tipos de datos, pero no su implementación.

Cohesión

La cohesión mide el grado de relación de los elementos dentro de un módulo. A mayor cohesión, mayor claridad, mantenibilidad y reutilización.

Cohesión Debil

1. Cohesión coincidente: Los elementos están juntos simplemente porque sí, puede ser en un mismo archivo pero sin relación funcional aparente.
2. Cohesión temporal: Los elementos son agrupados porque se ejecutan al mismo tiempo, pero no están conceptualmente relacionados.
3. Cohesión procesal: Los elementos se ejecutan uno tras otro, pero sin que haya una relación significativa entre ellos.
4. Cohesión lógica: Los elementos realizan funciones similares, pero no necesitan depender entre ellos para existir. Agruparlos puede dificultar la comprensión del propósito real del módulo.

Cohesión Media

1. Cohesión comunicacional: Los elementos operan sobre los mismos datos de entrada o producen salidas similares.
2. Cohesión secuencial: La salida de una parte sirve como entrada para otra dentro del mismo módulo.

Cohesión Fuerte

1. Cohesión de objetos: Cada parte del módulo contribuye a un propósito dentro del mismo dominio.
2. Cohesión funcional: Todos los elementos del módulo trabajan juntos para realizar una única tarea o comportamiento bien definido, orientado en un solo objetivo funcional.

Cohesión Alta vs. Cohesión Baja

Una alta cohesión indica que un componente tiene un propósito claro y bien definido, y que todas sus responsabilidades están alineadas. Por el contrario, un componente con baja cohesión tiene múltiples responsabilidades no relacionadas, lo que puede indicar la necesidad de dividirlo en varios componentes más específicos.

Al identificar una baja cohesión, es probable que podamos refactorizar el componente para mejorar su diseño, dividiendo sus responsabilidades en componentes más especializados y manejables”.

La cohesión en Función al Acoplamiento

De acuerdo con el Principio de Responsabilidad Única (SRP), una clase debe tener una única razón para cambiar. Al extender este principios a los paquetes de software, estos deberían agrupar clases que respondan a las mismas razones de cambio.

Para evitar la propagación de cambios en lugares no previstos, es fundamental mantener juntos aquellos elementos (clases/métodos/líneas de código) que comparten la misma naturaleza de cambio. Así, la cohesión de un elemento aumenta en la medida en que sus subelementos estén fuertemente relacionados entre sí (internamente acoplados) y dependan menos de elementos externos (clases/paquetes/contextos).

Por lo que, un componente será más cohesivo cuanto más acoplados estén sus componentes internos y menos dependa de componentes externos.

  +-------------------------+       +-----------------------+
  |     Componente A        |       |     Componente B      |
  |  +-----------------+    |       |  +-----------------+  |
  |  |  Sub-Elemento 1 | +  |       |  |  Sub-Elemento 1 |  |
  |  +-----------------+ |  |       |  +-----------------+  |
  |      |         ^     |  |       |      |         ^      |      
  |      v         |     |  |       |      v         |      |
  |  +-----------------+ |  |       |  +-----------------+  |
  |  |  Sub-Elemento 2 | |  |       |  |  Sub-Elemento 2 |  |
  |  +-----------------+ |  |       |  +-----------------+  |
  |      |         ^     |  |       |      |         ^      |      
  |      v         |     |  |       |      v         |      |
  |  +-----------------+ |  |       |  +-----------------+  |
  |  |  Sub-Elemento 3 | +  |       |  |  Sub-Elemento 3 |  |
  |  +-----------------+    |       |  +-----------------+  |
  +-------------------------+       +-----------------------+
              ^                              ^
              |                              |
              +------------------------------+
                      Bajo acoplamiento