Bajo acoplamiento

En el diseño de sistemas e informática, un sistema débilmente acoplado es uno

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

Ventajas y desventajas

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 se desacoplan 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 flexible (en disponibilidad), pero crea problemas para mantener la coherencia (sincronización de datos).

En integración

El acoplamiento flexible en un diseño de sistema distribuido más amplio se logra mediante el uso de transacciones, colas proporcionadas por middleware orientado a mensajes y estándares de interoperabilidad.

Cuatro tipos de autonomía, que promueven un acoplamiento flexible, son: autonomía de referencia, autonomía de tiempo, autonomía de formato y autonomía de plataforma. autonomía.

El acoplamiento flexible es un principio arquitectónico y un objetivo de diseño en arquitecturas orientadas a servicios; once formas de acoplamiento flojo y sus contrapartes de acoplamiento apretado se enumeran en:

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

El middleware Enterprise Service Bus (ESB) se inventó para lograr un acoplamiento flexible en múltiples dimensiones; sin embargo, los ESB sobrediseñados y mal colocados también pueden tener el efecto contrario y crear un acoplamiento estrecho no deseado y un punto de acceso arquitectónico central.

La arquitectura basada en eventos también tiene como objetivo promover un acoplamiento flexible.

Métodos para disminuir el acoplamiento

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

El acoplamiento flexible entre los componentes del programa se puede mejorar utilizando tipos de datos estándar en los parámetros. Pasar tipos de datos u objetos personalizados requiere que ambos componentes tengan conocimiento de la definición de datos personalizados.

Se puede mejorar el acoplamiento flexible de los servicios reduciendo la información pasada 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).

En programación

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

Un ejemplo de acoplamiento estrecho ocurre cuando una clase dependiente contiene un puntero directamente a una clase concreta que proporciona el comportamiento requerido. La dependencia no puede ser sustituida, ni su "firma" cambiado, sin requerir un cambio en la clase dependiente. El acoplamiento flojo 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 hacia un "contrato" especificado por la interfaz; una lista definida de métodos y/o propiedades que las clases de implementación deben proporcionar. Cualquier clase que implemente la interfaz puede 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. Un acoplamiento fuerte no lo permite.

Este es un diagrama UML que ilustra un ejemplo de acoplamiento libre 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 acoplamiento fuerte entre la clase dependiente y un proveedor:

Otras formas

Los lenguajes de programación informática que tienen nociones de funciones como módulo central (consulte 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. Vea Clojure y Lisp como ejemplos de lenguajes de programación de funciones. 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 independiente de cualquier otro concepto envolvente (por ejemplo, desacoplar una función de objeto de cualquier conocimiento directo del objeto envolvente). Consulte Función de primera clase para obtener más información sobre las funciones como objetos, lo que califica como una forma de función de primera clase.

Así, por ejemplo, en un lenguaje orientado a objetos, cuando se hace referencia a una función de un objeto como un objeto (liberándolo de tener conocimiento del objeto anfitrión que lo contiene), el nuevo objeto de función se puede pasar, almacenar y almacenar. llamado más tarde. Los objetos destinatarios (a quienes se entregan estos objetos funcionales) pueden ejecutar (llamar) de forma segura la función contenida a su propia conveniencia sin ningún conocimiento directo del objeto anfitrión circundante. De esta manera, un programa puede ejecutar cadenas o grupos de objetos funcionales, mientras está desacoplado de forma segura de tener cualquier referencia directa al objeto host circundante.

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

Por ejemplo: alguna entidad proporciona a otra un número de teléfono al que llamar para realizar un trabajo en particular. Cuando se llama al número, la entidad que llama efectivamente dice: "Por favor, haz este trabajo por mí". El desacoplamiento o el acoplamiento flojo se hace evidente inmediatamente. Es posible que la entidad que recibe el número al que llamar no tenga conocimiento de dónde proviene el número (por ejemplo, una referencia al proveedor del número). Por otro lado, la persona que llama está desacoplada del conocimiento específico de a quién llama, dónde está y de cómo opera internamente el receptor de la llamada.

Llevando el ejemplo un paso más allá, la persona 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". Nuevamente, la naturaleza débil o desacoplada de este objeto funcional es evidente. El receptor de la devolución de llamada no sabe qué o quién está siendo llamado. Sólo sabe que puede realizar la llamada y decide por sí mismo cuándo hacerlo. En realidad, es posible que la devolución de llamada ni siquiera sea para quien realizó la devolución de llamada en primer lugar. Este nivel de direccionamiento indirecto es lo que hace que los objetos funcionales sean una tecnología excelente para lograr programas débilmente acoplados.

La comunicación entre componentes débilmente acoplados puede basarse en una variedad de mecanismos, como el estilo de comunicación asincrónico mencionado o el estilo de paso de mensajes sincrónicos.

Acoplamiento de elementos de datos de medición

El grado de acoplamiento flojo se puede medir observando el número 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 aún continuarían comunicándose correctamente. Estos cambios incluyen elementos como:

1. Añadiendo nuevos elementos de datos a mensajes
2. Cambio del orden de elementos de datos
3. Cambiar los nombres de los elementos de datos
4. Cambio de estructuras de elementos de datos
5. Omitir elementos de datos