stringtranslate.com

Acoplamiento flojo

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

  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 desempeño 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 flojo 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 el diseño más amplio de sistemas distribuidos 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 un 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 arquitecturas orientadas a servicios . Once formas de acoplamiento flojo y sus contrapartes de acoplamiento apretado se enumeran en: [4]

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 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. [6]

Métodos para disminuir el acoplamiento.

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 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.

El acoplamiento flexible de los servicios se puede mejorar 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 es cuando una clase dependiente contiene un puntero directamente a una clase concreta que proporciona el comportamiento requerido. La dependencia no puede sustituirse ni cambiarse su "firma" sin que sea necesario 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 de 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 así 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 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:

Otras formas

Los lenguajes de programación de computadoras 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 funcionales. 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.

Por ejemplo, en un lenguaje orientado a objetos, cuando se hace referencia a la 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 llamar en un momento posterior. . 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 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. La entidad que recibe el número puede no tener conocimiento de su procedencia (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, haga este trabajo por mí. Llámeme a este número cuando haya 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 asíncrono mencionado o el estilo de paso de mensajes sincrónicos [7].

Acoplamiento de elementos de datos de medición

El grado de acoplamiento flojo 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 aún continuarí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. Omitir elementos de datos

Ver también

Referencias

  1. ^ Ligeramente acoplados: las piezas faltantes de servicios web por Doug Kaye
  2. ^ Pautasso C., Wilde E., ¿Por qué la Web está débilmente acoplada? Archivado el 12 de octubre de 2021 en Wayback Machine , Proc. de WWW 2009
  3. ^ F. Leymann Acoplamientos sueltos e implicaciones arquitectónicas Archivado el 2 de octubre de 2016 en Wayback Machine , discurso de apertura de ESOCC 2016
  4. ^ N. Josuttis, SOA en la práctica. O'Reilly, 2007, ISBN  978-0-596-52955-0 .
  5. ^ M. Keen et al, Patrones: implementación de una SOA utilizando un bus de servicios empresariales, IBM, 2004
  6. ^ Cómo EDA extiende SOA y por qué es importante Jack van Hoof
  7. ^ Mielle, Gregoire. "Patrones de microservicios: comunicación sincrónica versus asincrónica". Patrones de microservicios: comunicación sincrónica versus asincrónica . griego . Consultado el 18 de febrero de 2022 .