Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
4 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Todo mundo que já viu orientação a objetos alguma vez na vida conhece a frase "classes devem ter alta coesão e baixo acoplamento". Uma classe altamente acoplada pode ser sim um problema. Veja o diagrama abaixo, por exemplo, onde temos a classe GerenciadorDeNotaFiscal, que depende de outras 3 classes: um DAO, uma classe que envia e-mail e uma classe que se comunica com um serviço externo da empresa.
Acoplar-se a uma classe significa depender dela. E o problema de depender de outras classes é que, caso elas mudem, a classe principal pode sofrer mudanças também. No diagrama acima, se a classe Dao mudar sua interface ou mesmo o que ela faz, isso impactará na classe GerenciadorDeNotaFiscal. O mesmo aconteceria se as classes ServiçoExterno ou Email mudassem! Ou seja, quanto maior for a quantidade de classes dependentes, maior a chance de uma delas mudar e impactar em mudança na classe principal!
A ideia então é reduzir o acoplamento entre nossas classes o máximo possível. Mas sabemos que é impossível desenvolver sistemas com zero acoplamento. Mas será que todo e qualquer acoplamento é realmente problemático?
Arquitetura do Node.js: entenda o loop de eventos
Ler mais
Platform Engineering: o que é, quais os benefícios e melhores práticas
Ler mais
Imersão Game Dev: comece a criar seus próprios jogos
Ler maisPor exemplo, a grande maioria dos sistemas em Java no mundo são acoplados com a interface List (afinal a necessidade de guardar conjuntos de elementos é presente na maioria das aplicações). E fazer uso dessa interface geralmente não é problema para os desenvolvedores. Esse é um acoplamento "que não ligamos muito". A grande charada é entender a diferença entre o acoplamento com List e com o DAO, por exemplo.
A diferença é que a interface List não muda! Se ela não muda, isso significa que ela não forçará mudanças na classe que a usa! Ou seja, apesar de estarmos acoplados, o problema é menor, já que ela nunca provocará mudanças em nossos códigos!
Mas porque List não muda? Justamente por causa do acoplamento... o "outro lado do acoplamento"! Estamos sempre acostumados a ver o acoplamento como "a quantidade de classes que uma classe depende"; isso é conhecido como acoplamento eferente. Mas nunca vemos "a quantidade de classes que dependem de uma classe" (conhecido como acoplamento aferente).
A interface List, por exemplo, não depende de nada; mas muitas classes dependem dela. Veja a quantidade implementações da interface existentes: AbstractList, AbstractSequentialList, ArrayList, AttributeList, CopyOnWriteArrayList, LinkedList, RoleList, RoleUnresolvedList, Stack, Vector.
Isso sem contar a quantidade de classes que a referenciam hoje. Se algum engenheiro da Sun alterar essa interface, ele terá um trabalho imenso para propagar a mudança em muitos pontos. Portanto, provavelmente ele não fará isso! Isso torna essa interface estável!
Classes ou interfaces estáveis são aquelas que não tendem a mudar. Acoplar com classes ou interfaces com essa característica é interessante, pois sabemos que a chance dela mudar é baixa.
É por isso que interfaces são tão populares em códigos orientados a objeto. Interfaces tendem a ser estáveis, já que não possuem atributos ou implementação (coisas que tendem a mudar muito dentro de uma classe), e possuem muitas implementações embaixo dela (diminuindo a chance de algum programador mexer nela).
Entender bem as duas formas de acoplamento nos dá pontos de vista diferentes sobre a mesma classe. Se uma classe possui acoplamento eferente alto, isso significa que ela depende de muitas classes. E, para saber se esses acoplamentos são problemáticos, você pode medir o acoplamento aferente dessas dependências; se esse número for alto, essa classe tem a alta chance de ser estável, diminuindo o risco do acoplamento.
Evitar acoplamentos perigosos é tarefa importante. Você pode aprender mais sobre isso em nossos cursos online de Padrões de Projeto, no de Boas práticas em Orientação a Objetos ou em nosso livro de Test Driven Development.
Avalie este artigo
