Métricas del código: acoplamiento de clases
El acoplamiento de clases también se denomina "acoplamiento entre objetos" (CBO), tal y como se definió originalmente en CK94. Básicamente, el acoplamiento de clases es una medida del número de clases que usa una sola clase. Es malo que el número sea alto; en general, un número bajo suele ser bueno con esta métrica. Se ha demostrado que el acoplamiento de clases predice con precisión los errores de software. Según estudios recientes, un valor de límite máximo de 9 es lo más eficiente (S2010).
Según la documentación de Microsoft, el acoplamiento de clases "mide el acoplamiento a clases únicas a través de parámetros, variables locales, tipos de valor devuelto, llamadas de métodos, creaciones de instancias genéricas o de plantilla, clases base, implementaciones de interfaz, campos definidos en tipos externos y decoración de atributos. Según el buen diseño de software, los tipos y métodos deben tener una cohesión alta y un acoplamiento bajo. Un acoplamiento alto es indicio de un diseño difícil de reutilizar y mantener debido a sus muchas interdependencias en otros tipos”.
Los conceptos de acoplamiento y cohesión están claramente relacionados. Para ceñirnos al tema que estamos tratando, no profundizaremos en el aspecto de la cohesión, sino que únicamente aportaremos una breve definición procedente de KKLS2000:
"La cohesión del módulo es un concepto que Yourdon y Constantine definieron como 'cuán estrechamente enlazados o relacionados entre sí están los elementos internos de un módulo' (YC79). Un módulo tiene una fuerte cohesión si representa exactamente una tarea […] y todos sus elementos contribuyen a esta única tarea. Describen la cohesión como un atributo de diseño, en lugar de código, que se puede usar para predecir la reusabilidad, el mantenimiento y la capacidad de modificación".
Ejemplo de acoplamiento de clases
Veamos el acoplamiento de clases en acción. En primer lugar, cree una aplicación de consola y una clase denominada Person con algunas propiedades en ella. A continuación, calcule inmediatamente las métricas de código:
Observe que el acoplamiento de clases es 0, ya que esta clase no utiliza ninguna otra clase. Ahora cree otra clase denominada PersonStuff con un método que cree una instancia de Person y establezca los valores de propiedad. Vuelva a calcular las métricas del código:
¿Ve cómo sube el valor de acoplamiento de clases? Observe también que, independientemente del número de propiedades que establezca, el valor de acoplamiento de clases solo sube 1, y no más. El acoplamiento de clases mide cada clase solo una vez para esta métrica, independientemente de cuánto se use. Además, ¿se ha fijado en que DoSomething() tiene un valor de 1, pero el constructor PersonStuff() tiene un valor de 0? Actualmente no hay código en el constructor que use otra clase.
¿Qué ocurre si coloca en el constructor código que usó otra clase? Esto es lo que obtiene:
Ahora el constructor tiene claramente código que usa otra clase y la métrica de acoplamiento de clases así lo demuestra. De nuevo, puede ver que el acoplamiento de clases general para PersonStuff() es 1 y para DoSomething() también es 1, lo que muestra que solo se usa una clase externa, independientemente de cuánto código interno la use.
A continuación, cree otra clase. Asigne un nombre a esta clase y cree algunas propiedades dentro de ella:
Ahora consuma la clase en nuestro método DoSomething() dentro de la clase PersonStuff y vuelva a calcular las métricas del código:
Como puede ver, el acoplamiento de clases de la clase PersonStuff sube a 2. Si explora en profundidad la clase, puede ver que el método DoSomething() es el que más acoplamiento tiene, pero el constructor sigue consumiendo solo una clase. Con estas métricas, puede ver el número máximo general de una clase determinada y explorar los detalles en profundidad por miembro.
El "número mágico"
Al igual que sucede con la complejidad ciclomática, no existe un límite que se adapte a todas las organizaciones. A pesar de ello, en S2010 se indica que un límite de 9 es óptimo:
"Por lo tanto, consideramos que los valores de umbral […] son los más eficaces. Estos valores de umbral (para un solo miembro) son CBO = 9[…]". (énfasis añadido)
Análisis de código
El análisis de código incluye una categoría de reglas de mantenimiento. Para obtener más información, consulte Reglas de mantenimiento. Al usar el análisis de código heredado, el conjunto de reglas de directrices de diseño extendidas contiene un área de mantenimiento:
El área de mantenimiento incluye una regla para el acoplamiento de clases:
Esta regla emite una advertencia cuando el acoplamiento de clases es excesivo. Para obtener más información, consulte CA1506: Cómo evitar el acoplamiento excesivo de clases.
Citas
CK94
Chidamber, S. R.y& Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, vol. 20, n.º 6). Consultado el 14 de mayo de 2011 en el sitio web de la Universidad de Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf
KKLS2000
Kabaili, H., Keller, R., Lustman, F. y Saint-Denis, G. (2000). Class Cohesion Revisited: An Empirical Study on Industrial Systems (actas del taller Quantitative Approaches in Object-Oriented Software Engineering). Consultado el 20 de mayo de 2011 en el sitio web de la Universidad de Montreal: http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf
SK2003
Subramanyam, R. y Krishnan, M. S. (2003). Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, vol. 29, n.º 4).
S2010
Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, vol. 36, n.º 2).
YC79
Edward Yourdon y Larry L. Constantine. Structured Design. Prentice Hall, Englewood Cliffs, N.J., 1979.