Introdução
Não importa qual linguagem de programação você usa para construir um sistema funcional — seu código estará repleto de dependências externas. Tanto é que surgiram diversos gerenciadores de dependência: como o BOSS no Delphi, o npm no JavaScript, o pip no Python, o Cargo no Rust, o Go modules no Go, entre outros. Todos eles existem por um motivo simples:
Você está sempre dependendo de código que não escreveu.
Esclarecimento
Antes de seguir, vale um esclarecimento importante. Nesta série, vamos usar dois termos genéricos para deixar tudo claro desde o início:
- Recurso externo: qualquer coisa que seu código utiliza, mas que você não escreveu com as próprias mãos. Pode ser uma função de biblioteca, uma classe de framework, um módulo baixado ou algo gerado automaticamente.
- Recurso interno: qualquer coisa que você escreveu deliberadamente, com domínio sobre seu funcionamento — mesmo que, às vezes, nem você entenda mais direito.
O Ponto Central é simples:
Se o seu código depende de um recurso — seja interno ou externo — ele está acoplado.
E quanto mais você ignora isso, mais transforma essa dependência em uma armadilha. Se o seu código precisa de algo para funcionar, ele está acoplado.
E quanto mais invisível for esse vínculo, mais perigoso ele pode se tornar.
Quando você encontra um recurso que facilita sua vida, você acopla esse recurso ao seu projeto — geralmente sem pensar duas vezes. A partir desse momento, seu código passa a depender dele. Isso é acoplamento.
Agora pense: quando você escreve seu próprio código — sem recorrer a bibliotecas — você se preocupa com acoplamento? Chega a perder o sono tentando evitar ao máximo o acoplamento entre os próprios recursos que criou? Se sim, poderia me dizer o motivo?
Parece que as linguagens, em geral, não se preocupam tanto assim com o acoplamento.
Ao iniciar um novo projeto, mesmo antes de escrever a primeira linha de código…
o acoplamento já está lá: discreto, silencioso. E você provavelmente nem notou.
Exemplo prático em Delphi
unit Unit1;
interface
uses
System.SysUtils,
System.Types,
System.UITypes,
System.Classes,
System.Variants,
FMX.Types,
FMX.Controls,
FMX.Forms,
FMX.Graphics,
FMX.Dialogs;
type
TForm1 = class(TForm)
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.fmx}
end.
Percebeu?
Só de criar um novo projeto, seu código já está acoplado a diversos recursos pela cláusula uses.E aqui vai um detalhe importante:
No Delphi, ao declarar uma unit no uses, todo o conteúdo público daquela unit é automaticamente incluído na compilação — não importa se você vai usar uma ou cem funcionalidades desse recurso. O vínculo está feito.E mais: o compilador não reclama se você não usar nada dessas units.
Esse acoplamento silencioso pode parecer inofensivo, mas ele injeta dependências invisíveis no seu projeto, tornando-o mais pesado e, potencialmente, mais frágil a mudanças externas.
Linguagens como Go, por exemplo, não permitem isso — se você importar um recurso e não usá-lo, o compilador acusa erro.
Conclusão
Acoplamento não é algo que surge apenas quando usamos recursos de terceiros. Ele está presente desde o primeiro momento — nas fundações do projeto, nos arquivos gerados automaticamente, nas units que o compilador exige e que muitas vezes nem questionamos.
A verdadeira pergunta não é:
“Como evitar o acoplamento?”
Mas sim:
“Como lidar com o acoplamento de forma consciente e controlada?”
Ignorar o acoplamento só nos torna reféns dele.
Entendê-lo nos dá poder para projetar sistemas mais flexíveis, sustentáveis e menos frágeis com o tempo.
E talvez o mais importante — mais do que seguir qualquer mantra de “baixo acoplamento” — seja entender:
- O que está sendo acoplado.
- Por que está sendo acoplado.
- E quais as consequências disso.
Porque no fim das contas, acoplar é inevitável — Mas fazer isso com consciência é opcional.
Na próxima parte da série, vamos mergulhar nos tipos de acoplamento: estrutural, funcional, temporal e outros — com exemplos práticos e reflexões que vão além dos livros didáticos.
Porque entender acoplamento é como enxergar a arquitetura invisível do seu código. E só quem enxerga, consegue mudar.
TheCodeNaked
Onde o código é exposto. Só não vê quem não quer.
