O código funciona, mas por que, ao abrir um arquivo para corrigir uma funcionalidade, precisamos mexer em tantos lugares?
Você muda a cor de um botão e a lógica de pagamento quebra. Todo mundo já passou por isso alguma vez.
Os conceitos que explicam essa causa em duas palavras são acoplamento e coesão.
Quanto menor o acoplamento, melhor; quanto maior a coesão, melhor. Grande parte de um bom design começa com essa frase.
Neste artigo, explico o que esses conceitos significam exatamente, por que são chamados de raízes dos princípios de design de software e como aplicá-los ao código real, com base na minha experiência.
Vamos começar resumindo os pontos principais.
- Acoplamento: quanto os módulos ficam entrelaçados → quanto menor, melhor
- Coesão: quanto o código de um módulo se concentra em uma única tarefa → quanto maior, melhor
- Esses dois conceitos formam a base de princípios conhecidos, como SOLID e padrões de projeto.
- O objetivo é um só: código fácil de alterar e substituir.
Acoplamento e coesão: afinal, o que são?
Se resumirmos primeiro os dois conceitos em uma frase, fica assim.
Acoplamento é a relação entre módulos, enquanto coesão é a união interna de um módulo.
Como apontam em direções opostas, é fácil confundir os dois. Eu memorizei assim.
Acoplamento é a “distância do exterior”; coesão é a “união interior”.
Quando o acoplamento é alto, corrigir A arrasta B e C junto. Como um dominó.
Quando a coesão é baixa, a lógica de pagamento, o envio de e-mails e os logs ficam misturados em uma classe. Só pelo nome, não dá para saber o que ela faz.
Um bom design leva os dois em direções opostas: frouxo por fora, firme por dentro.
Por que isso é a “raiz” dos princípios de design?
Acoplamento e coesão foram organizados pela primeira vez na teoria de design estruturado dos anos 1970. A proposta é geralmente atribuída a Larry Constantine.
Eles continuam válidos quase meio século depois porque representam fundamentos que não dependem de uma linguagem ou tendência específica.
Quando analisamos os princípios conhecidos, todos acabam convergindo para cá.
| Princípio · Padrão | O que realmente querem dizer |
|---|---|
| Princípio da Responsabilidade Única (SRP) | Aumente a coesão |
| Princípio da Inversão de Dependência (DIP) | Reduza o acoplamento |
| Princípio da Segregação de Interfaces (ISP) | Elimine acoplamentos desnecessários |
| A maioria dos padrões de projeto | Baixo acoplamento + alta coesão |
Viu? Os nomes mudam, mas a raiz é uma só.
Quando aprendo um princípio ou padrão novo, primeiro pergunto: “Isso serve para reduzir o acoplamento ou aumentar a coesão?”. Assim, entendo metade.
Como reduzir o acoplamento? Vejamos no código.
Como falar sozinho pode parecer abstrato, vamos ver um exemplo curto.
O código abaixo tem alto acoplamento. A classe Order conhece diretamente uma empresa de pagamentos específica.
class Order {
let pay = KakaoPay() // Acoplado diretamente ao Kakao Pay
func checkout() {
pay.send() // Para trocar por outro pagamento, é preciso desmontar isto
}
}No momento em que você troca o provedor por Toss, precisa abrir Order e alterá-lo. Esse é o exemplo clássico de alto acoplamento.
Agora vamos criar distância usando um protocolo.
class Order {
let pay: Payment // 'Depende apenas do contrato de “pagamento”
init(pay: Payment) { self.pay = pay }
func checkout() { pay.send() } // Não importa o que chegar
}Agora Order não se importa com qual provedor de pagamentos chega. Basta trocar a implementação.
Depois de fazer essa alteração no trabalho, quase não precisei tocar no código existente quando surgiram pedidos para adicionar provedores de pagamento. Esse é o poder do baixo acoplamento.
Como aumentar a coesão?
A coesão é avaliada perguntando se o módulo faz exatamente uma coisa.
Meu critério é simples: quando você diz o nome de uma classe, se todos os seus métodos vêm naturalmente à mente, ela tem alta coesão.
Por exemplo, encontrar isto misturado em UserService é um sinal de alerta.
- Processamento do cadastro de usuários (responsabilidade principal)
- Envio de e-mails de marketing (trabalho de outra pessoa)
- Geração de relatórios CSV (outro trabalho de outra pessoa)
É como se tarefas sem relação morassem de aluguel na mesma casa.
Nesse caso, dê ao e-mail seu próprio cômodo com EmailSender e aos relatórios outro com ReportGenerator.
Assim, depois você não precisará abrir UserService para alterar a lógica de e-mail. O impacto das mudanças diminui.
Baixo acoplamento e alta coesão, no fim, apontam para a mesma direção: impedir que as mudanças se espalhem.
Perguntas frequentes (Q&A)
P. Entre acoplamento e coesão, em qual devo focar primeiro?
Recomendo começar pela coesão. Ao dividir os módulos para que cada um se concentre em uma responsabilidade, o acoplamento muitas vezes se organiza naturalmente.
P. Acoplamento zero é sempre melhor?
Não. Se os módulos não tiverem nenhuma conexão, o programa não funciona. O objetivo não é zero, mas “apenas o necessário, de forma frouxa”.
P. Preciso projetar tudo perfeitamente desde o início?
Não é necessário. Eu também faço funcionar primeiro e, quando as alterações começam a doer, vou desfazendo o acoplamento e aumentando a coesão aos poucos. Refatoração é algo naturalmente iterativo.
Acoplamento e coesão não são tecnologias novas e chamativas, mas hábitos comuns de quem escreve código duradouro.
No código que você escreveu hoje, pergunte uma vez: “Se eu corrigir isto, até onde o impacto vai chegar?”. Ao repetir essa pergunta, seu senso de design cresce rapidamente. Torcendo por você!