Cohesión y acoplamiento

En la facultad cursé una asignatura llamada "Técnicas de Diseño". El equipo que llevaba la asignatura no era una gran autoridad en el tema del diseño de software, temática de la materia, y el responsable de la cátedra tenía muchos defectos, pero debo reconocer que era una persona sumamente convencida de sus ideas. Quizás más por amor propio que otra cosa. En cualquier caso, él estaba convencido de que la cohesión y el acoplamiento eran dos conceptos fundamentales en el diseño de soluciones informáticas. Y la verdad es que tiene toda la razón.

Voy a intentar definir cohesión y acoplamiento, desde el punto de vista informático. La cohesión es el grado de cercanía entre dos o más elementos. Podríamos decir que es un conjunto de características que los une y, por lo tanto, los agrupa bajo un mismo denominador, define su identidad. El acoplamiento, en cambio, mide el grado de dependencia entre dos o más elementos. Esto quiere decir que, según su dependencia, estarán más o menos acoplados. Mayor dependencia implica mayor acomplamiento.

El objetivo final del diseño de software (o soluciones informáticas) en materia de estos dos conceptos es: Reducir al máximo el acoplamiento entre componentes y aumentar la cohesión interna de cada componente.

¿Qué quiere decir reducir el acoplamiento? Básicamente, lo más importante es saber definir las responsabilidades de cada componente para garantizar que la dependencia sea funcional o arquitectónica, no de implementación. Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. ¿Qué ocurre en ese caso? Pues que el resultado del comportamiento del componente A dependerá del valor del componente B, por lo tanto, están acoplados. Cabe destacar que el acoplamiento no es malo, ojo. Simplemente hay que saber eliminar el acoplamiento que no sea funcional o arquitectónico. En el caso de acoplamiento funcional, está bien que un componente de cálculo de probabilidades dependa de un componente de cálculo matemático básico, ya que es evidente que para calcular probabilidades será necesario aplicar fórmulas matemátics y resolver operaciónes aritméticas. En el caso de acoplamiento arquitectónico, se puede ver un ejemplo en el esquema MVC (modelo-vista-controlador). La capa del modelo realizará cambios de acuerdo con los parámetros que recibe del controlador, por lo tanto hay cierta dependencia, pero sólo como separación de capas de una arquitectura claramente definida.

¿Qué ocurre en el caso de la cohesión? La cohesión de un componente mide la identidad de su comportamiento. El comportamiento de un componente se define mediante una serie de operaciones (contrato), cada una de ellas con una responsabilidad y función. La suma de todas las operaciones que definen dicho comportamiento integran una identidad. La cohesión no es buena cuando nos encontramos con que hay operaciones con un objetivo junto a otras con otro objetivo dentro de un mismo componente, cuya definición funcional es una y clara. Un ejemplo claro y sencillo de esto es el siguiente. Imaginemos un componente que gestiona el estado de una ficha de datos personales. Lo lógico sería que su contrato tuviese operaciones como "Actualizar nombres y apellidos", "Eliminar teléfono de contacto" y demás. Si defino una operación que calcula el pronóstico del tiempo en Tombuctú para el próximo fin de semana, pues la cohesión se anula completamente, ya que nada tiene que ver con el resto de operaciones y, sobretodo, con el fin del componente.

Con esto propongo un debate sobre estos dos conceptos, para enriquecernos entre todos y mejorar el uso que hacemos de ello a diario en nuestros diseños. Aunque no lo parezca, aplicamos estas ideas constantemente, en todos los niveles de un equipo de desarrollo de soluciones informáticas.

Un saludo para todos.