Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo Java Magazine 76 - Baixo Acoplamento
No artigo, abordaremos os diversos tipos de acoplamento de forma tanto conceitual quanto aplicada (com exemplos concretos).
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
[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 divulgado, 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 diversos 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 individual 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 mais importantes e discutidos, até por isso foi nosso exemplo inicial.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
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 divulgado, 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 diversos 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 individual 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 mais importantes e discutidos, até por isso foi nosso exemplo inicial.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal Java
Publicidade
Osvaldo Pinali Doederlein
Space do autor
é 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.
Space do autor
0
0
