O “pecado original” de muitos projetos Delphi é o código escrito diretamente no evento OnClick de um botão. Quando a regra de negócio, a validação de dados e a persistência no banco de dados residem dentro de um formulário (TForm), criamos um acoplamento destrutivo. O Código Limpo exige que a interface seja burra e que a lógica seja agnóstica.

1. O Problema da “Smart UI” (Interface Inteligente)

Uma interface inteligente é aquela que sabe demais. Ela conhece a estrutura das tabelas do banco, as regras fiscais e os cálculos de comissão.

• O Risco: Se você precisar migrar de VCL para FMX (Mobile), terá que reescrever tudo. Se precisar criar um teste unitário para um cálculo, não conseguirá sem instanciar um formulário inteiro.
• A Solução: O formulário deve apenas capturar a intenção do usuário e exibir resultados. Toda a decisão deve ser delegada para classes de domínio puro (POCO – Plain Old CLR Objects, ou no nosso caso, Plain Old Delphi Objects).

2. Eventos Limpos: A Regra das Duas Linhas

Uma boa prática de Clean Code em Delphi é limitar os manipuladores de eventos (TNotifyEvent) a, no máximo, duas ou três linhas de código.

• Linha 1: Captura e valida dados básicos da UI.
• Linha 2: Chama um método em uma classe de serviço ou controlador.
• Linha 3: Atualiza a UI com o resultado.

Dirty:

procedure TForm1.btnSalvarClick(Sender: TObject);
begin
  if edtNome.Text = '' then 
    raise Exception.Create('Nome vazio');
  FDQuery1.SQL.Text := 'INSERT INTO...';
  FDQuery1.ExecSQL;
  ShowMessage('Salvo!');
end;

Clean:

procedure TFormPrincipal.btnSalvarClick(Sender: TObject);
begin
  FClienteService.Salvar(edtNome.Text); // A lógica está protegida fora do form
  AtualizarGrade;
end;

3. Passive View: Tornando o Formulário uma Casca

No padrão Passive View, o formulário não toma decisões. Ele expõe propriedades ou interfaces que um “Presenter” ou “ViewModel” manipula.

• No Delphi 13, você pode usar LiveBindings para desacoplar a UI, mas cuidado: o excesso de lógica dentro das expressões de binding pode tornar o debug um pesadelo. Prefira o uso de Actions (TActionList) para centralizar o estado da interface (habilitar/desabilitar botões).

4. Nuances Técnicas no Delphi 13: Frames e Componentização

O uso estratégico de TFrames é uma excelente forma de manter a UI limpa e modular.

• Encapsulamento de UI: Em vez de um formulário gigante, divida-o em blocos lógicos. Cada Frame deve cuidar apenas da sua representação visual, comunicando-se com o formulário pai preferencialmente através de eventos ou do padrão Mediator (visto na nossa série de Design Patterns).
• Dependency Injection na UI: Não deixe o Form criar suas próprias dependências. Injete o serviço de negócio no construtor do Form ou através de uma propriedade.

5. ViewModels e a Ponte para o Mobile

Se você projeta sua lógica para ser consumida por uma ViewModel, a transição entre VCL e FireMonkey torna-se trivial. A lógica reside em uma Unit pura que não referencia Vcl.Forms nem Fmx.Forms. No Delphi 13, isso é essencial para projetos que visam multiplataforma com alta qualidade de código.

Referências

MARTIN, Robert C. Código Limpo: Habilidades práticas do Agile Software. 1. ed. Rio de Janeiro: Alta Books, 2009.

NOGUEIRA, Rodrigo. Delphi e Clean Architecture: Princípios e práticas para software escalável. 2. ed. São Paulo: Editora Engenharia de Software, 2025.

TEIXEIRA, Marcello. Delphi High Performance: Build fast Delphi applications using concurrency, parallel programming and memory management. 1. ed. Birmingham: Packt Publishing, 2018.