Polimorfismo, Binding e Generics

Aula 7 — Programação Orientada a Objetos

Marcos M. Raimundo — Instituto de Computação, UNICAMP

2026-08-30

Proposta da Aula

A pergunta da Aula 6: como Pagavel forma aceita ora Pix, ora Cartao?

A resposta: Polimorfismo — múltiplas formas atrás do mesmo contrato.

Roteiro: Late Binding → taxonomia → fim do “Mar de IFs” → Generics.

Polimorfismo e o Mecanismo de Late Binding

O que é Polimorfismo?

“Muitas formas”: a mesma chamada, comportamentos diferentes, dependendo do objeto real.

Late Binding: Quem Decide, e Quando

Pagavel forma = opcoes.get(escolha - 1); // compilador so sabe: e um Pagavel
String id = forma.criarCobranca(total);  // JVM decide o codigo real, EM RUNTIME

Compilador: checa que o método existe. JVM: decide qual implementação roda.

A Taxonomia de Cardelli-Wegner

Universal: Inclusão e Paramétrico

Inclusão: qualquer implementação de Pagavel serve — pilar da OO.

Paramétrico: List<T> funciona igual para qualquer tipo, sem herança.

Ad-hoc: Sobrecarga e Coerção

public void enviar(String email) { ... }
public void enviar(String email, String assunto) { ... } // sobrecarga

“Polimorfismo aparente”: um tipo novo exige voltar e reescrever Notificador — viola OCP.

Estático vs. Dinâmico

	Static Binding	Dynamic Binding
Quando	Compilação	Execução
Quem decide	Compilador	JVM
Vantagem	Performance	Desacoplamento total

Taxonomia do Polimorfismo

Por que a sobrecarga de métodos é chamada de “polimorfismo aparente”, mesmo permitindo múltiplas versões do mesmo nome de método?

Escreva sua resposta e compare com um colega antes de avançar (2 min).

□ O polimorfismo ad-hoc funciona apenas sobre um conjunto finito e delimitado de tipos.
□ A sobrecarga (overloading) é resolvida pelo compilador em tempo de compilação, com base nos argumentos passados.
□ O polimorfismo de inclusão é resolvido em tempo de execução, olhando o objeto real na memória.
□ A sobrecarga de métodos resolve completamente o problema da extensibilidade prevista pelo OCP.

Taxonomia do Polimorfismo — Resposta

Por que a sobrecarga de métodos é chamada de “polimorfismo aparente” — Resposta

✔ O polimorfismo ad-hoc funciona apenas sobre um conjunto finito e delimitado de tipos — é a definição de ad-hoc.
✔ A sobrecarga (overloading) é resolvida pelo compilador em tempo de compilação, com base nos argumentos passados — é Early Binding.
✔ O polimorfismo de inclusão é resolvido em tempo de execução, olhando o objeto real na memória — é Late Binding, o pilar do desacoplamento em OO.
✗ A sobrecarga de métodos resolve completamente o problema da extensibilidade prevista pelo OCP — pelo contrário, é considerada “polimorfismo aparente”, que não resolve extensibilidade.

Voltando à pergunta: a sobrecarga escolhe a versão certa em tempo de compilação, olhando a assinatura — não o objeto real em runtime; por isso não é o polimorfismo que sustenta o desacoplamento da OO.

O Fim do “Mar de IFs” e o Princípio Aberto/Fechado

Antes: o “Mar de IFs”

if (tipo.equals("PIX")) pixService.gerarQR(valor);
else if (tipo.equals("BOLETO")) boletoService.gerarLinhaDigitavel(valor);
else if (tipo.equals("CARTAO")) cartaoService.autorizar(valor);
// novo tipo = mais um else if

Depois: Uma Linha, Fechada para Modificação

String id = formaEscolhida.criarCobranca(total); // nao muda nunca

Meta-regra: precisar de if/switch/instanceof sobre tipo de negócio = sintoma de OCP violado.

OCP e Substitutibilidade

Se amanhã surgir um novo meio de pagamento, o que exatamente muda no CheckoutController — e o que isso diz sobre o OCP?

Escreva sua resposta e compare com um colega antes de avançar (2 min).

□ Adicionar Cripto implements Pagavel exige alterar o código do CheckoutController.
□ “Aberto para extensão” significa que novos comportamentos entram por novas classes, não por edição das antigas.
□ Precisar de instanceof para decidir o que fazer com um objeto de negócio é sinal de que o polimorfismo não foi bem aproveitado.
□ A substitutibilidade é o que permite ao CheckoutController tratar Pix, Boleto e Cripto de forma idêntica.

OCP e Substitutibilidade — Resposta

Se amanhã surgir um novo meio de pagamento, o que muda no CheckoutController — Resposta

✗ Adicionar Cripto implements Pagavel exige alterar o código do CheckoutController — é exatamente o ponto: nenhuma linha do controlador muda.
✔ “Aberto para extensão” significa que novos comportamentos entram por novas classes, não por edição das antigas — é a definição de “aberto para extensão”.
✔ Precisar de instanceof para decidir o que fazer com um objeto de negócio é sinal de que o polimorfismo não foi bem aproveitado — é a meta-regra prática desta aula.
✔ A substitutibilidade é o que permite ao CheckoutController tratar Pix, Boleto e Cripto de forma idêntica — é a substitutibilidade via Pagavel.

Voltando à pergunta: nada muda no CheckoutController — é exatamente isso que o OCP promete: extensão via novas classes, sem tocar no código que já funciona.

Generics: da Lista “Aceita-Tudo” à Etiqueta de Tipo

O Problema dos Raw Types

opcoesReais.add("Nao sou um pagamento"); // compila; falha so depois

Erro de lógica na inserção → ClassCastException bem mais tarde, longe da causa.

A Solução: Generics como Etiqueta

List<Pagavel> opcoesReais = ...;
// opcoesReais.add("string"); // ERRO DE COMPILACAO, agora

4 vantagens: robustez, legibilidade, reutilização, performance (menos casts).

Generics e o Fim do Mar de IFs

Generics é uma instância de qual tipo de polimorfismo na taxonomia de Cardelli-Wegner — e por que ele não exige que os tipos usados pertençam à mesma hierarquia de herança?

Escreva sua resposta e compare com um colega antes de avançar (2 min).

□ Sem Generics, um erro de tipo numa coleção só é detectado quando o item incompatível é efetivamente usado, não quando é inserido.
□ List<Pagavel> impede, em tempo de compilação, que um objeto incompatível seja adicionado à lista.
□ Generics é uma forma de Polimorfismo Ad-hoc, resolvida da mesma forma que a sobrecarga de métodos.
□ Precisar de um if para verificar o tipo concreto de um objeto de negócio é um sintoma de violação do OCP.

Generics e o Fim do Mar de IFs — Resposta

Generics na taxonomia de Cardelli-Wegner — Resposta

✔ Sem Generics, um erro de tipo numa coleção só é detectado quando o item incompatível é efetivamente usado, não quando é inserido — é a “detecção tardia” descrita nesta aula.
✔ List<Pagavel> impede, em tempo de compilação, que um objeto incompatível seja adicionado à lista — é o ganho central de Generics.
✗ Generics é uma forma de Polimorfismo Ad-hoc, resolvida da mesma forma que a sobrecarga de métodos — Generics é Polimorfismo Universal Paramétrico, resolvido de forma bem diferente da sobrecarga.
✔ Precisar de um if para verificar o tipo concreto de um objeto de negócio é um sintoma de violação do OCP — é a meta-regra do bloco anterior.

Voltando à pergunta: Generics é Polimorfismo Universal Paramétrico — o mesmo algoritmo de lista serve para qualquer tipo, sem exigir que os tipos compartilhem hierarquia de herança.

Conclusão

O que Aprendemos

Late Binding: a JVM decide, em runtime, qual código roda
Universal (Inclusão, Paramétrico) vs. Ad-hoc (Sobrecarga, Coerção)
Polimorfismo elimina o “Mar de IFs” — a essência prática do OCP
Generics: a mesma robustez de tipo, sem abrir mão da flexibilidade

Próxima aula: Herança — o outro mecanismo de polimorfismo, e o Princípio da Substituição de Liskov.