Acoplamiento flojo

En informática y diseño de sistemas , un sistema débilmente acoplado es aquel

1. en el que los componentes están débilmente asociados (tienen relaciones rompibles) entre sí, y por lo tanto los cambios en un componente afectan menos la existencia o el rendimiento de otro componente.
2. en el que cada uno de sus componentes tiene, o hace uso de, poco o ningún conocimiento de las definiciones de otros componentes separados. Las subáreas incluyen el acoplamiento de clases , interfaces, datos y servicios. ^[1] El acoplamiento flexible es lo opuesto al acoplamiento estricto.

Los componentes de un sistema débilmente acoplado se pueden reemplazar con implementaciones alternativas que brinden los mismos servicios. Los componentes de un sistema débilmente acoplado están menos restringidos a la misma plataforma, lenguaje , sistema operativo o entorno de compilación.

Si los sistemas están desacoplados en el tiempo, es difícil proporcionar también integridad transaccional; se requieren protocolos de coordinación adicionales. La replicación de datos entre diferentes sistemas proporciona un acoplamiento débil (en cuanto a disponibilidad), pero crea problemas para mantener la coherencia ( sincronización de datos ).

El acoplamiento flexible en el diseño de sistemas distribuidos más amplios se logra mediante el uso de transacciones, colas proporcionadas por middleware orientado a mensajes y estándares de interoperabilidad. ^[2]

Cuatro tipos de autonomía que promueven el acoplamiento flexible son: autonomía de referencia , autonomía de tiempo , autonomía de formato y autonomía de plataforma . ^[3]

El acoplamiento flexible es un principio arquitectónico y un objetivo de diseño en las arquitecturas orientadas a servicios . Se enumeran once formas de acoplamiento flexible y sus contrapartes de acoplamiento estricto en: ^[4]

• conexiones físicas a través de mediador,
• estilo de comunicación asincrónica ,
• tipos comunes simples solo en el modelo de datos ,
• sistema de tipo débil,
• mensajes autónomos y centrados en datos,
• control distribuido de la lógica del proceso,
• vinculación dinámica (de consumidores y proveedores de servicios),
• independencia de plataforma,
• compensación a nivel empresarial en lugar de transacciones a nivel de sistema,
• despliegue en diferentes momentos,
• actualizaciones implícitas en el control de versiones.

El middleware Enterprise Service Bus (ESB) se inventó para lograr un acoplamiento flexible en múltiples dimensiones. ^[5] Sin embargo, los ESB sobrediseñados y mal ubicados también pueden tener el efecto contrario y crear un acoplamiento estrecho no deseado y un punto crítico arquitectónico central.

La arquitectura basada en eventos también tiene como objetivo promover el acoplamiento flexible. ^[6]

El acoplamiento flexible de interfaces se puede mejorar publicando datos en un formato estándar (como XML o JSON ).

El acoplamiento flexible entre los componentes del programa se puede mejorar mediante el uso de tipos de datos estándar en los parámetros. Para pasar tipos de datos u objetos personalizados, es necesario que ambos componentes conozcan la definición de datos personalizada.

El acoplamiento flexible de los servicios se puede mejorar reduciendo la información que se pasa a un servicio a los datos clave. Por ejemplo, un servicio que envía una carta es más reutilizable cuando solo se pasa el identificador del cliente y se obtiene la dirección del cliente dentro del servicio. Esto desacopla los servicios porque no es necesario llamarlos en un orden específico (por ejemplo, GetCustomerAddress, SendLetter).

El acoplamiento se refiere al grado de conocimiento directo que un componente tiene de otro. El acoplamiento débil en informática se interpreta como encapsulación versus no encapsulación.

Un ejemplo de acoplamiento fuerte es cuando una clase dependiente contiene un puntero directamente a una clase concreta que proporciona el comportamiento requerido. La dependencia no se puede sustituir, o su "firma" cambiar, sin requerir un cambio en la clase dependiente. El acoplamiento débil ocurre cuando la clase dependiente contiene un puntero solo a una interfaz, que luego puede ser implementada por una o varias clases concretas. Esto se conoce como inversión de dependencia . La dependencia de la clase dependiente es a un "contrato" especificado por la interfaz; una lista definida de métodos y/o propiedades que las clases implementadoras deben proporcionar. Cualquier clase que implemente la interfaz puede, por lo tanto, satisfacer la dependencia de una clase dependiente sin tener que cambiar la clase. Esto permite la extensibilidad en el diseño de software. Se puede escribir una nueva clase que implemente una interfaz para reemplazar una dependencia actual en algunas o todas las situaciones, sin requerir un cambio en la clase dependiente; las clases nuevas y antiguas se pueden intercambiar libremente. El acoplamiento fuerte no permite esto.

Este es un diagrama UML que ilustra un ejemplo de acoplamiento flexible entre una clase dependiente y un conjunto de clases concretas, que proporcionan el comportamiento requerido:

A modo de comparación, este diagrama ilustra el diseño alternativo con un fuerte acoplamiento entre la clase dependiente y un proveedor:

Los lenguajes de programación informática que tienen nociones de funciones como módulo central (véase Programación funcional ) o funciones como objetos proporcionan excelentes ejemplos de programación débilmente acoplada. Los lenguajes funcionales tienen patrones de Continuaciones , Cierres o generadores. Véase Clojure y Lisp como ejemplos de lenguajes de programación funcional. Los lenguajes orientados a objetos como Smalltalk y Ruby tienen bloques de código, mientras que Eiffel tiene agentes. La idea básica es objetivar (encapsular como un objeto) una función independientemente de cualquier otro concepto envolvente (por ejemplo, desacoplar una función de objeto de cualquier conocimiento directo del objeto envolvente). Véase Función de primera clase para obtener más información sobre las funciones como objetos, que califica como una forma de función de primera clase.

Por ejemplo, en un lenguaje orientado a objetos, cuando se hace referencia a una función de un objeto como un objeto (liberando así a la función de tener cualquier conocimiento del objeto anfitrión que la contiene), el nuevo objeto de función se puede pasar, almacenar y llamar en un momento posterior. Los objetos destinatarios (a quienes se les dan estos objetos funcionales) pueden ejecutar (llamar) de forma segura la función contenida a su conveniencia sin ningún conocimiento directo del objeto anfitrión que la contiene. De esta manera, un programa puede ejecutar cadenas o grupos de objetos funcionales, mientras que se desacopla de forma segura de tener cualquier referencia directa al objeto anfitrión que la contiene.

Los números de teléfono son un excelente análogo y pueden ilustrar fácilmente el grado de esta disociación.

Por ejemplo, una entidad proporciona a otra un número de teléfono para que realice un trabajo en particular. Cuando se llama al número, la entidad que llama está diciendo en realidad: "Por favor, haz este trabajo por mí". La disociación o el acoplamiento débil es evidente de inmediato. La entidad que recibe el número puede no tener conocimiento de dónde proviene el número (por ejemplo, una referencia al proveedor del número). Por otro lado, la persona que llama no tiene conocimiento específico de a quién está llamando, dónde está y no sabe cómo opera internamente el receptor de la llamada.

Llevando el ejemplo un paso más allá, el que llama podría decirle al receptor de la llamada: "Por favor, haz este trabajo por mí. Llámame a este número cuando hayas terminado". El "número" que se ofrece al receptor se denomina "devolución de llamada". Una vez más, la naturaleza desacoplada o de acoplamiento débil de este objeto funcional es evidente. El receptor de la devolución de llamada no sabe a qué o a quién se está llamando. Sólo sabe que puede realizar la llamada y decide por sí mismo cuándo llamar. En realidad, la devolución de llamada puede no ser ni siquiera para quien la proporcionó en primer lugar. Este nivel de indirección es lo que hace que los objetos de función sean una excelente tecnología para lograr programas de acoplamiento débil.

La comunicación entre componentes acoplados de forma flexible puede basarse en una variedad de mecanismos, como el estilo de comunicación asincrónica mencionado o el estilo de paso de mensajes sincrónico ^[7].

El grado de acoplamiento débil se puede medir observando la cantidad de cambios en los elementos de datos que podrían ocurrir en los sistemas de envío o recepción y determinando si las computadoras seguirían comunicándose correctamente. Estos cambios incluyen elementos como:

1. Agregar nuevos elementos de datos a los mensajes
2. Cambiar el orden de los elementos de datos
3. Cambiar los nombres de los elementos de datos
4. Cambiar las estructuras de los elementos de datos
5. Omisión de elementos de datos

• Fallo en cascada
• Cohesión (informática)
• Connascence (programación informática)
• Acoplamiento (informática)
• Bus de servicios empresariales
• Interfaz de programación de aplicaciones
• Ley de Deméter
• Separación de preocupaciones
• Arquitectura orientada a servicios
• Arquitectura basada en el espacio (SBA)