Polimorfismo, Binding e Generics

Aula 7 — Programação Orientada a Objetos

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

2026-08-26

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

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).

Taxonomia do Polimorfismo

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

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

Taxonomia do Polimorfismo — Resposta

Dica

  1. Verdadeiro — é a definição de ad-hoc.
  2. Verdadeiro — é Early Binding.
  3. Verdadeiro — é Late Binding, o pilar do desacoplamento em OO.
  4. Falso — pelo contrário, é considerada “polimorfismo aparente”, que não resolve extensibilidade.

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.

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).

OCP e Substitutibilidade

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

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

OCP e Substitutibilidade — Resposta

Dica

  1. Falso — é exatamente o ponto: nenhuma linha do controlador muda.
  2. Verdadeiro — é a definição de “aberto para extensão”.
  3. Verdadeiro — é a meta-regra prática desta aula.
  4. Verdadeiro — é a substitutibilidade via Pagavel.

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 é 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).

Generics e o Fim do Mar de IFs

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

  1. Sem Generics, um erro de tipo numa coleção só é detectado quando o item incompatível é efetivamente usado, não quando é inserido.
  2. List<Pagavel> impede, em tempo de compilação, que um objeto incompatível seja adicionado à lista.
  3. Generics é uma forma de Polimorfismo Ad-hoc, resolvida da mesma forma que a sobrecarga de métodos.
  4. 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

Dica

  1. Verdadeiro — é a “detecção tardia” descrita nesta aula.
  2. Verdadeiro — é o ganho central de Generics.
  3. Falso — Generics é Polimorfismo Universal Paramétrico, resolvido de forma bem diferente da sobrecarga.
  4. Verdadeiro — é a meta-regra do bloco anterior.

Conclusão

O que Aprendemos

  1. Late Binding: a JVM decide, em runtime, qual código roda
  2. Universal (Inclusão, Paramétrico) vs. Ad-hoc (Sobrecarga, Coerção)
  3. Polimorfismo elimina o “Mar de IFs” — a essência prática do OCP
  4. 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.