Quando o if não decide mais — ele delega (mas nem sempre precisa) (Copy)

Imagine um código como este:

if TipoPagamento = tpCartao then
  ProcessaCartao
else if TipoPagamento = tpBoleto then
  ProcessaBoleto
else
  ProcessaPix;

Clássico. Direto. Legível.

Mas também bastante acoplado: o fluxo principal está decidido por ramificações específicas baseadas em valores.

E aí entra uma daquelas máximas que circulam por aí:

“Você ainda usa if porque não conhece polimorfismo…”

🧠 Mas o que é, afinal, esse tal de polimorfismo?

Polimorfismo é a capacidade de usar um mesmo nome para chamar ações diferentes, dependendo do tipo do objeto.

No exemplo anterior, em vez de decidir com if, poderíamos fazer:

Pagamento.Processar;

Agora, Pagamento pode ser:

• TPagamentoCartao
• TPagamentoBoleto
• TPagamentoPix

E cada uma dessas classes implementa seu próprio Processar.

🪜 Mas... um passo atrás.

De onde vem esse objeto Pagamento?

Para que essa chamada funcione, alguém precisa criar o objeto certo:

function CriarPagamento(Tipo: TTipoPagamento): TPagamento;
begin
  case Tipo of
    tpCartao: Result := TPagamentoCartao.Create;
    tpBoleto: Result := TPagamentoBoleto.Create;
    tpPix:    Result := TPagamentoPix.Create;
  else
    raise Exception.Create('Tipo de pagamento inválido');
  end;
end;

Pronto. O if (ou case) continua lá.
Só mudou de endereço.

🎯 Quando polimorfismo faz sentido?

✅ Exemplo 1 — Benefício real:

Imagine um relatório de pagamentos. Agora queremos imprimir, salvar em PDF, e exportar para Excel dependendo do tipo de pagamento.

Em vez de vários ifs espalhados, podemos ter:

for Pag in ListaDePagamentos do
  Pag.Exportar;

Cada tipo sabe como se exportar.
Isso é poder. Isso é clareza.

❌ Exemplo 2 — Desnecessário:

Mas se só existe um lugar no sistema onde precisamos verificar o tipo e chamar uma ação…

if TipoPagamento = tpCartao then
  ShowMessage('Pagamento com cartão processado');

...então criar três classes, uma hierarquia e um construtor é só formalidade disfarçada de arquitetura.

📌 Polimorfismo não elimina acoplamento — apenas o transfere

Você não está mais acoplado ao tipo do valor.
Agora está acoplado à estrutura da classe.
E adivinha? O if está lá, criando os objetos.

A escolha, portanto, não é entre acoplado e desacoplado —
é entre onde você quer acoplar e por quê.

🧾 Conclusão

O polimorfismo pode ser elegante — desde que necessário.
Não vale a pena criar abstrações só porque "um dia pode surgir um novo meio de pagamento".

Se o dia chegar, reescreva.
A abstração que resolve um problema inexistente é apenas vaidade disfarçada de precaução.

No TheCodeNaked, o if não é vilão.
Ele é só um personagem. Às vezes principal. Às vezes coadjuvante.
Mas imortal, por enquanto.

Você pode esconder o if, renomeá-lo, deslocá-lo...
Mas ele vai continuar ali, sorrindo no canto do código.
O if é como a gravidade: não dá pra eliminar, só aprender a lidar.

Se quiser, posso:

• Dividir esse artigo em carrossel por etapas (Didático)
• Criar uma arte para a frase final (perfeita pra redes)
• Avançar para o próximo: "Quando a tabela pensa por você"

Como deseja seguir?