Acoplamento solto - Loose coupling

Em computação e design de sistemas, um sistema fracamente acoplado é um

em que os componentes estão fracamente associados (têm relacionamento quebrável) entre si e, portanto, as mudanças em um componente afetam menos a existência ou o desempenho de outro componente.
em que cada um de seus componentes tem, ou faz uso de, pouco ou nenhum conhecimento das definições de outros componentes separados. As subáreas incluem o acoplamento de classes, interfaces, dados e serviços. O acoplamento frouxo é o oposto do acoplamento firme.

Vantagens e desvantagens

Os componentes em um sistema fracamente acoplado podem ser substituídos por implementações alternativas que fornecem os mesmos serviços. Os componentes em um sistema fracamente acoplado são menos restritos à mesma plataforma, linguagem , sistema operacional ou ambiente de construção.

Se os sistemas forem desacoplados no tempo, será difícil também fornecer integridade transacional ; protocolos de coordenação adicionais são necessários. A replicação de dados em diferentes sistemas fornece acoplamento fraco (na disponibilidade), mas cria problemas na manutenção da consistência ( sincronização de dados ).

Em integração

O acoplamento fraco em um design de sistema distribuído mais amplo é obtido pelo uso de transações, filas fornecidas por middleware orientado a mensagens e padrões de interoperabilidade.

Quatro tipos de autonomia, que promovem o acoplamento fraco, são: autonomia de referência , autonomia de tempo , autonomia de formato e autonomia de plataforma .

O acoplamento fraco é um princípio arquitetônico e objetivo de design em arquiteturas orientadas a serviços ; onze formas de acoplamento frouxo e suas contrapartes de acoplamento apertado estão listadas em:

conexões físicas via mediador,
estilo de comunicação assíncrona ,
tipos comuns simples apenas no modelo de dados ,
sistema de tipo fraco,
mensagens centradas em dados e independentes,
controle distribuído da lógica do processo,
vinculação dinâmica (de consumidores e provedores de serviço),
independência de plataforma,
compensação em nível de negócios, em vez de transações em nível de sistema,
implantação em momentos diferentes,
atualizações implícitas no controle de versão.

O middleware Enterprise Service Bus (ESB) foi inventado para obter um acoplamento fraco em várias dimensões; no entanto, ESBs com engenharia excessiva e mal posicionados também podem ter o efeito contrário e criar um acoplamento forte indesejado e um ponto de acesso arquitetônico central.

A arquitetura orientada a eventos também visa promover um acoplamento fraco.

Métodos para diminuir o acoplamento

O acoplamento fraco de interfaces pode ser aprimorado publicando dados em um formato padrão (como XML ou JSON ).

O acoplamento fraco entre os componentes do programa pode ser aprimorado usando tipos de dados padrão em parâmetros. A transmissão de tipos ou objetos de dados customizados requer que ambos os componentes tenham conhecimento da definição de dados customizados.

O acoplamento fraco de serviços pode ser aprimorado reduzindo as informações passadas em um serviço para os dados-chave. Por exemplo, um serviço que envia uma carta é mais reutilizável quando apenas o identificador do cliente é passado e o endereço do cliente é obtido dentro do serviço. Isso separa os serviços porque os serviços não precisam ser chamados em uma ordem específica (por exemplo, GetCustomerAddress, SendLetter).

Em programação

O acoplamento se refere ao grau de conhecimento direto que um componente tem de outro. O acoplamento fraco na computação é interpretado como encapsulamento vs. não encapsulamento.

Um exemplo de acoplamento rígido ocorre quando uma classe dependente contém um ponteiro diretamente para uma classe concreta que fornece o comportamento necessário. A dependência não pode ser substituída, ou sua "assinatura" alterada, sem exigir uma mudança para a classe dependente. O acoplamento fraco ocorre quando a classe dependente contém um ponteiro apenas para uma interface, que pode então ser implementado por uma ou várias classes concretas. A dependência da classe dependente é para um "contrato" especificado pela interface; uma lista definida de métodos e / ou propriedades que as classes de implementação devem fornecer. Qualquer classe que implemente a interface pode, portanto, satisfazer a dependência de uma classe dependente sem ter que mudar a classe. Isso permite extensibilidade no design de software; uma nova classe implementando uma interface pode ser escrita para substituir uma dependência atual em algumas ou todas as situações, sem exigir uma mudança na classe dependente; as classes novas e velhas podem ser trocadas livremente. O forte acoplamento não permite isso.

Este é um diagrama UML que ilustra um exemplo de acoplamento fraco entre uma classe dependente e um conjunto de classes concretas, que fornecem o comportamento necessário:

Para comparação, este diagrama ilustra o design alternativo com forte acoplamento entre a classe dependente e um provedor:

Outras formas

As linguagens de programação de computador com noções de funções como o módulo central (consulte Programação funcional ) ou funções como objetos fornecem excelentes exemplos de programação fracamente acoplada. As linguagens funcionais têm padrões de continuação , fechamento ou geradores. Veja Clojure e Lisp como exemplos de linguagens de programação de funções. Linguagens orientadas a objetos como Smalltalk e Ruby possuem blocos de código, enquanto Eiffel possui agentes. A ideia básica é objetivar (encapsular como um objeto) uma função independente de qualquer outro conceito envolvente (por exemplo, desacoplar uma função de objeto de qualquer conhecimento direto do objeto envolvente). Consulte Função de primeira classe para obter mais informações sobre funções como objetos, que se qualificam como uma forma de função de primeira classe.

Assim, por exemplo, em uma linguagem orientada a objetos, quando uma função de um objeto é referenciada como um objeto (liberando-o de ter qualquer conhecimento de seu objeto host envolvente), o novo objeto de função pode ser passado, armazenado e chamado em um mais tarde. Objetos destinatários (para quem esses objetos funcionais são fornecidos) podem executar (chamar) com segurança a função contida em sua própria conveniência, sem qualquer conhecimento direto do objeto host que os envolve. Desta forma, um programa pode executar cadeias ou grupos de objetos funcionais, enquanto seguramente desacoplado de ter qualquer referência direta ao objeto host envolvente.

Os números de telefone são um excelente analógico e podem ilustrar facilmente o grau desse desacoplamento.

Por exemplo: alguma entidade fornece a outra um número de telefone para a qual ligar para realizar um trabalho específico. Quando o número é chamado, a entidade que está ligando está efetivamente dizendo: "Por favor, faça este trabalho para mim." O desacoplamento ou acoplamento frouxo é imediatamente aparente. A entidade que recebe o número para ligar pode não ter conhecimento de onde veio o número (por exemplo, uma referência ao fornecedor do número). Por outro lado, o chamador é desvinculado do conhecimento específico de quem está ligando, de onde está e de como o receptor da chamada opera internamente.

Levando o exemplo um passo adiante, o chamador pode dizer ao receptor da chamada: "Por favor, faça este trabalho para mim. Ligue-me de volta neste número quando terminar." O 'número' oferecido ao destinatário é denominado "Call-back". Novamente, o acoplamento fraco ou natureza desacoplada desse objeto funcional é aparente. O destinatário da chamada de retorno não sabe o que ou quem está sendo chamado. Ele só sabe que pode fazer a chamada e decide por si mesmo quando ligar. Na realidade, o retorno de chamada pode não ser nem mesmo para quem fez o retorno em primeiro lugar. Esse nível de indireção é o que torna os objetos de função uma tecnologia excelente para obter programas fracamente acoplados.

Medindo o acoplamento do elemento de dados

O grau de acoplamento fraco pode ser medido observando o número de mudanças nos elementos de dados que poderiam ocorrer nos sistemas de envio ou recebimento e determinando se os computadores continuariam se comunicando corretamente. Essas mudanças incluem itens como:

Adicionar novos elementos de dados às mensagens
Alterar a ordem dos elementos de dados
Alterar os nomes dos elementos de dados
Alterar as estruturas dos elementos de dados
Omitindo elementos de dados

Languages

In other projects