👻 OOP - Parte 1 - Acoplamento - Episódio 1

🎬 Episódio 1: O Acoplamento é discreto: ele já está no seu código e você provavelmente nem notou.

Não importa a linguagem de programação que você use 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, e muitos outros. Todos eles existem por um motivo simples: você está sempre dependendo de código que não escreveu.

Antes de seguir, vale um esclarecimento importante:
Aqui nesta série, usaremos dois termos genéricos para deixar tudo claro desde o início:

• Recurso externo: qualquer coisa que seu código usa, 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 ele interno ou externo —, ele está acoplado.

E quanto mais você ignora isso, mais você transforma dependência em armadilha.

Se o seu código depende de algum recurso para funcionar, 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ê simplesmente o acopla 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ê está escrevendo seu próprio código — sem recorrer a recursos — você se preocupa com acoplamento? Chega a perder o sono tentando evitar ao máximo o acoplamento entre recursos criados por você? Se sim, poderia me dizer o motivo? Parece que as linguagens no geral não se preocupam tanto assim com acoplamentos.

Ao iniciar um novo projeto, sem fazer uso de nenhum recurso — mesmo antes de você escrever a primeira linha de código... ele já está lá: o acoplamento, 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 em uses, todo o conteúdo público daquela unit é automaticamente incluído na compilação. Não importa se você vai usar apenas uma funcionalidade 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 o erro.

🧨 No Delphi, o silêncio pode ser perigoso.

⚠️ Conclusão

Acoplamento não é algo que surge apenas quando usamos recursos de terceiros. Ele está presente desde o primeiro momento, embutido nas fundações do projeto, nos arquivos gerados automaticamente, nas unidades 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 deixa reféns dele. Entendê-lo, por outro lado, nos dá poder para projetar sistemas mais flexíveis, sustentáveis e menos frágeis com o tempo.

E talvez, mais importante que seguir qualquer mantra de “baixo acoplamento” seja entender o que está sendo acoplado, por que, e quais são 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 — explorando 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.