Durante mi carrera, he visto muchísimas veces a los desarrolladores de software mencionar esta frase en algún code review:
Es que el código está muy acoplado
– Developer confundido
Bien, decidí hacer este post para que todo aquel que lo lea quizás salga con un mejor entendimiento de que es lo que estas palabras rimbombantes significan. Y no solo las usen para verse inteligente frente a sus colegas.
Dada la importancia de la modularidad del software, es importante que tengamos las herramientas adecuadas para poder entenderla. Y para nuestra fortuna los investigadores en el ramo han creado suficientes herramientas para entender los aspectos clave de la modularidad.
Nos vamos a enfocar en 3 conceptos principales:
- Cohesión
- Acoplamiento
- connascencia
Cohesión
La cohesión se refiere a que tantas partes de un módulo deberían estar contenidas dentro del mismo módulo. En otras palabras mide que tan relacionadas están las partes de algún módulo dado.
Entonces Idealmente un módulo cohesivo es aquel donde todas las partes deberían estar empacadas juntas porque si se separan en piezas más atómicas entonces estaríamos creando acoplamiento, es decir módulos que dependen mucho entre sí.
Existen varios tipos de Chesión:
- Cohesión Funcional
Cada parte del módulo está relacionada con la otra, y el módulo contiene todo lo esencial para funcionar.
- Cohesión Secuencial
Dos módulos interactúan, donde la salida de uno se convierte en la entrada del otro.
- Cohesión Comunicacional
Cuando dos módulos forman una cadena de comunicación y colaboran para una salida en común. Por ejemplo escribir un registro en una base de datos, y mandar una notificación del registro por email.
- Cohesión Procedural
Dos módulos se deben ejecutar en un orden específico.
- Cohesión Temporal
Cuando los módulos están relacionados basándose en una relación de tiempo entre sus dependencias. Como por ejemplo cuando hay una serie de módulos que necesitan ciertas características cargadas cuando se inicia la aplicación (Un módulo de repositorios que necesita que antes de ser utilizado se establezca la conexión a la base de datos.).
- Cohesión Lógica
Cuando los datos entre módulos están relacionados lógicamente pero no funcionalmente. Por ejemplo podríamos considerar un módulo que convierte información de texto plano a objetos serializables o streams. Estas operaciones están relacionadas. pero sus funciones son bastante diferentes.
- Cohesión Coincidencial
Los elementos en un módulo no están relacionados con otra cosa mas que estar en el mismo archivo fuente. Y por lo general esto representa un anti-patrón.
Ahora bien, durante años los científicos han estudiado la cohesión en el software y han descubierto formas de decir que tan cohesivas son nuestras aplicaciones.
Chidamber y Kemerer introduce el Lack Of Cohesion in Methods (LCOM) Este método establece una fórmula matemática para determinar el nivel de cohesión en un módulo.
Sea C1 una clase con métodos M1, M2,…, Mn. Entonces. {Ii} sea el conjunto de atributos
\begin{equation}
LCOM =
\begin{cases}
|P| - |Q| \text{, si } |P| > |Q| \\
0, \text{en cualquier otro caso}\\
\end{cases}
\end{equation}En esta primera versión P es el número de pares de métodos que no acceden a ningún atributo común de C1 y Q es el número de pares de métodos que acceden al menos a un atributo común de C1. Por tanto, si la cardinalidad de P es mayor que la de Q, LCOM viene dada por la diferencia del número de pares de métodos sin atributos compartidos y el número de pares de métodos con atributos compartidos.
Luego en 1996, Henderson-Sellers introducen una nueva versión de esta ecuación:
\begin{equation}
LCOM96b = \frac{1}{a} \sum_{j=1}^{a}\frac{m-\mu(Aj)}{m}
\end{equation}donde a es el número de atributos, y m(Aj) es la medida que da 0 si cada método de la clase hace referencia a todos los atributos, y 1 si cada método de una clase hace referencia a un solo atributo.