¿Cómo puedo saber si el software está altamente acoplado?

Estoy familiarizado con el término "altamente acoplado", pero tengo curiosidad por saber si hay signos (olores de código) que puedan indicar que el código está altamente acoplado. Actualmente estoy trabajando con Java EE pero esto puede aplicarse a cualquier idioma.

Editar:

En caso de que alguien esté interesado, este artículo suena útil: En busca de la calidad del código: ¡ Cuidado con la pareja apretada! (IBM)

El indicador número uno de módulos mal acoplados en mi opinión son las dependencias bilaterales. Por ejemplo, el Módulo 1 llama a alguna función en el Módulo 2 y el Módulo 2 llama a alguna función en el Módulo 1.

La mayoría de las interfaces deben ser unidireccionales. Si el módulo al que se llamó necesita pasar alguna información al módulo de llamada que no se devuelve como parte de la llamada, entonces debería usar algún tipo de mecanismo de activación de eventos o paso de mensajes, como una cola de mensajes. Idealmente, el identificador para pasar la interfaz del mensaje debe pasarse durante algún proceso de inicialización o registro. Esto abstrae completamente la interfaz de tal manera que al módulo no le importa para quién es el evento ... por lo tanto, está desacoplado.

Otra indicación es cuando un módulo llama constantemente a otro módulo para un conjunto de datos específico. Esto debería hacerle preguntar quién debería ser el propietario del conjunto de datos. ¿Por qué este módulo en cuestión siempre necesita ver datos que pertenecen a otro módulo?

Una tercera herramienta, por así decirlo, es preguntarse: "¿Puedo extraer este módulo y reemplazarlo sin requerir cambios en otros módulos?

De ninguna manera es una lista exhaustiva, pero son las tres cosas principales que me pregunto cuando diseño un software.

El viejo dicho de diseño es: "Puedes tocar a tus amigos y a tus amigos. Pero no puedes tocar a tus amigos". Eso es acoplamiento en pocas palabras.

Los signos de código altamente acoplado incluyen interfaces muy grandes que permiten a las personas conocer detalles privados de la implementación y objetos que parecen "conocerse mucho entre sí". Existen herramientas para el análisis automático que marcarán el código que se ve estrechamente acoplado para usted. Consulte http://www.scitools.com/features/metricsintro.php para obtener uno aleatorio. (No tengo idea de qué tan bien funciona. Simplemente apareció bastante alto en una búsqueda en Google).

Intenta escribir algunas pruebas unitarias para las clases. Si no puede probar fácilmente las clases sin la necesidad de crear / simular cargas de clases de soporte o un db / ui, entonces es un signo seguro de mal acoplamiento / dependencias.

También es una de las mejores curas, pero debes hacerlo durante la codificación (como TDD) para mantenerte honesto.

La señal obvia para mí es que todo es público.

El otro signo son las violaciones de la Ley de Demeter: esto es excesivo. Algunas referencias de SomeObj.SomeProp.SomeProp en interfaces no fluidas.

Una vez vi lo que he denominado una "clase de puppetmaster" que creó un formulario de entrada de datos sobre la marcha. Tenía varias otras violaciones de diseño de software, por lo que el acoplamiento excesivo era la menor de sus preocupaciones.

Cuando recuperó datos de los controles que creó, lo hizo así:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

El efecto dominó .

Cada cambio tiene un efecto dominó en todos los módulos estrechamente acoplados.

Se ha violado el principio de "Abierto-Cerrado" porque no está correctamente cerrado y el cambio se filtra.

Verifique el número de # include / imports, etc. entre clases / paquetes / dlls / jars / whatnots. Intenta dibujar un gráfico de esto, mentalmente, manualmente o usando algún tipo de herramienta.

• Si ese gráfico es denso (es decir, muchas conexiones por todo el lugar), entonces su sistema es monolítico y altamente acoplado.
• Si está claramente dividido en capas, sin conexiones a través de / a través de capas, y las conexiones son pocas, tiene un sistema modular y desacoplado.

Si le resulta imposible implementar una función porque no tiene idea de a dónde va una responsabilidad específica, entonces su sistema está demasiado ajustado.

Para signos muy básicos, puede considerar buscar el número de interfaces y su uso entre clases de diferentes paquetes (generalmente el código débilmente acoplado contiene interfaces y hay una interacción directa limitada entre las clases individuales en diferentes paquetes), el número de nombres de clase que pueden ser se usa para agrupar otras clases (en código débilmente acoplado, la interacción real entre clases que tienen diferentes trabajos se realiza mediante funciones de interfaz o funciones de clases más comunes / agrupadas) o numerar variables públicas dentro de clases (más libremente mucho menos / incluso ninguna variable pública )

Casi todos los olores de código indican un acoplamiento superfluo de alguna manera. Supongo que el olor que más indicaría el acoplamiento podría ser "Intimidad inapropiada" (mi olor favorito).

Supongo que otro método razonable para medir sería contar las líneas en su diagrama UML. Si tiene N objetos y N ^ N (o más) líneas entre ellos, entonces su código está prácticamente acoplado al máximo. Las líneas N probablemente serían tan mínimas como puedas obtener.