Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Diz-se que um projeto está altamente acoplado quando suas classes e módulos conhecem muito um do outro, criando uma grande dependência entre eles. Isto acontece, na maioria das vezes, devido a uma decisão errada, tomada pelo projetista, que aos poucos encaminha o projeto para um design caótico onde uma simples manutenção de rotina pode desencadear uma série de erros em outro ponto do projeto.

O grande vilão, que pode tornar uma alteração pequena em um verdadeiro desastre é o relacionamento entre as classes, por isso é vantajoso investir o tempo necessário (ou possível), para criar designs onde as classes sejam capazes de se relacionar conhecendo o mínimo uma da outra. Criar classes coerentes que dependem apenas de interfaces é uma das formas de garantir o baixo acoplamento, porém o princípio “programe para interface”, sozinho não ajudará muito.

O problema do alto acoplamento

Podemos medir o quão fortemente as classes de uma aplicação estão conectadas, possuem conhecimento ou dependem de outra classe observando o acoplamento existente em cada caso. Quanto mais acoplada uma classe estiver de outra maior o risco de termos uma combinação dos seguintes problemas:

· Mudanças numa classe relacionada forçam alterações locais à classe para que o funcionamento seja mantido;

· O reuso da classe torna-se mais difícil uma vez que sua implementação depende de outras classes;

· A coesão da classe diminui na medida em que aumenta o acoplamento caso ela assuma parte das responsabilidades de outra classe;

· A classe não pode ser testada isoladamente já que depende de testes em conjunto com outras classes, aumentando inclusive o esforço de entendimento.

Percebemos rapidamente que diminuindo ao máximo o acoplamento além de evitarmos os problemas mencionados anteriormente tornaremos nossa aplicação mais flexível e fácil de ser mantida, especialmente em equipes com paralelismo de desenvolvimento de atividades correlatas.

Utilizando as corretas técnicas e ferramentas para injeção de dependência, diversos componentes podem ser desenvolvidos paralelamente (aproveitando de recursos como Mock Objects para auxiliar nos testes unitários) e sua aplicação se tornará mais plugável e flexível, exigindo um esforço menor para modificações.

Técnicas para resolver o problema de alto acoplamento

Tomemos como exemplo uma classe chamada ClasseA que depende dos serviços Servico1 e Servico2, conforme a Figura 1.

Figura 1. Dependência entre classes

Se em algum momento necessitarmos substituir ou atualizar alguma das suas dependências, a classe ClasseA sofrerá alterações em seu código, uma vez que está relacionada diretamente com as classes de serviço. Outro ponto é que as implementações concretas das dependências precisam estar disponíveis no momento da compilação da solução. Uma das soluções seria delegar a função de selecionar a implementação da classe concreta para um componente (ou um container) externo. "