#Este é um post fechado

Este post está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais sobre como abrir este post!

Artigo Java Magazine 76 - Baixo Acoplamento

No artigo, abordaremos os diversos tipos de acoplamento de forma tanto conceitual quanto aplicada (com exemplos concretos).

Osvaldo Pinali Doederlein é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.

Ver space do autor

Estatísticas:

Visualizações:

1741

Favoritado:

0 vez(es)

Serviços:

Inclua seu próprio artigo! (ajuda)

Inclua um comentário

Adicionar aos Favoritos

Marcar como lido/assistido

Incluir anotação pessoal (ajuda)

RSS Feeds

Versão para impressão

Java Magazine 76

[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]

> Clique aqui para ler todos os artigos da Java Magazine 76

Baixo Acoplamento
Todos os aspectos de uma boa prática muito citada, mas pouco entendida
Software de qualidade deve ter “baixo acoplamento” (loose coupling), mas o que isso significa? Muita coisa

Este artigo é dedicado a explorar o conceito de baixo acoplamento. O termo em sido muito ulgado, principalmente desde o aparecimento das tecnologias de web services e SOA, mas seu significado é bem mais amplo e atinge todos os aspectos do desenvolvimento de software, da análise até a programação. Podemos chamar o baixo acoplamento de um “meta-paradigma”, uma boa-prática de grande alcance que pode ser integrada como princípio fundamental de qualquer metodologia ou ferramenta de desenvolvimento.
Tentaremos explicar a importância do baixo acoplamento, mostrar como este conceito se aplica de forma concreta em ersos artefatos de um projeto de software, e oferecer diretrizes para incorporar esta boa prática ao seu trabalho.
O que é Acoplamento
A definição formal é simples: Acoplamento é o grau de dependência entre dois artefatos. Esta dependência é uma medida da quantidade de informações que um artefato deve possuir sobre o outro para que as colaborações necessárias entre ambos possam ocorrer. “Artefato” pode ser praticamente qualquer coisa que faz parte do projeto – uma classe, método, componente, pacote, tabela, protocolo de comunicação, sistema externo, ator (inclusive humano), documento, etc.
Para definições mais detalhadas, minha fonte favorita é esta wiki, que trata dos conceitos afins de acoplamento e coesão: c2.com/cgi/wiki?CouplingAndCohesion.
Exemplo: Acoplamento de APIs
Começando por um exemplo concreto de acoplamento de código, vou recorrer a um dos exemplos didáticos mais manjados, um sistema bancário. Temos um cliente web ou móvel, que deseja conectar-se ao banco e obter um extrato dos últimos 30 dias de movimento para uma conta. Isso pode ser implementado de várias formas, de acordo com a interface remota do sistema bancário.

Banco banco = ... // Algum tipo de lookup: JNDI, web service, etc.
Map<Integer, Agencia> agencias = banco.getAgencias();
Agencia ag = agencias.get(1234);
Map<Integer, Conta> contas = ag.getContas();
Conta conta = contas.get(999999);
List<Lancamento> = conta.getUltimosLancamentos(30);
Utilizei variáveis intermediárias (como agencias) apenas para expor a interface das classes utilizadas. Algumas variáveis poderiam ser eliminadas, por exemplo Agencia ag = banco.getAgencias().get(1234), mas isso não teria qualquer impacto sobre a discussão de acoplamento.
Este primeiro exemplo ilustra um nível de acoplamento alto entre o programa cliente e o sistema bancário, pois a API deste sistema expõe muitos detalhes internos: a existência de vários objetos (Banco, Agencia e Conta); os relacionamentos entre eles (“1 Banco tem N Agencias”), e mesmo as estruturas de dados usadas para manipular estes relacionamentos (como um Set<Integer, Agencia>). Cada elemento inidual da interface do sistema bancário está destacado em negrito; isso oferece uma visão simples (ainda que grosseira) da quantidade de acoplamento.
Compare isso com um design de baixo acoplamento para o mesmo problema:

Banco banco = ... // Algum tipo de lookup: JNDI, web service, etc.
List<Lancamento> = banco.getUltimosLancamentos(1234, 999999, 30);

Nesta segunda versão, Banco implementa o design pattern Facade, expondo de forma direta todos os métodos úteis para clientes externos, como getUltimosLancamentos(). Cada método desses recebe todos os parâmetros necessários para o contexto da operação, como no caso, os códigos da agência e da conta – assim, não precisamos expor os objetos Agencia e Conta, nem seus relacionamentos.
A importância do Acoplamento Fraco
Devemos procurar reduzir o acoplamento entre artefatos do sistema, pelo motivo bem conhecido de facilitar a evolução independente de cada um destes artefatos. No exemplo, se mudarmos alguma coisa nos relacionamentos Banco/Agencia/Conta, a primeira versão do nosso código de consulta de extrato poderá precisar de alterações, mas a segunda versão não precisará. (O leitor poderá argumentar que isso é um benefício do design pattern Facade, mas a redução de acoplamento é um dos objetivos deste pattern, bem como vários outros.)
Acoplamento de Código
Vamos nos estender um pouco mais sobre o acoplamento de código, que é um dos tipos de acoplamento ma >">