Herança: DNA, Fragilidade e Template Method

Aula 8 — Programação Orientada a Objetos

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

2026-08-30

Proposta da Aula

Interface define o que o objeto faz. Herança define o que ele é.

É o acoplamento mais forte da Orientação a Objetos — e, por isso, o mais perigoso mal utilizado.

Roteiro: mecânica → fragilidade → quando herdar → classes abstratas → Template Method.

Herança: do Contrato à Identidade

extends: a Relação “É-UM”

public abstract class MeioPagamentoBase implements Pagavel {
    protected String idCobranca; // estado compartilhado
}
public class Cartao extends MeioPagamentoBase { private double limite; }

Herança de atributos é incorporação física — não associação externa.

A Fragilidade sem final

public void alterarStatus(String novoStatus) { this.status = novoStatus; } // ignora o pai!

Sem private + final, a invariante do pai é apenas uma “sugestão”.

O Problema da Classe Base Frágil

public void processarLote(List<Double> v) {
    for (double x : v) processarPagamento(x); // polimorfismo desvia para o FILHO
}

Resultado esperado: 3. Resultado real: 6 — contagem duplicada por confiar na mecânica interna do pai.

Quando Herdar, e Quando Não

Herança por Conveniência: o Erro

GerenciadorDeCobrancas extends ListaDeContatos — o gerenciador usa uma lista, não é uma lista.

Vaza métodos do pai (limpar, remover) + poluição de tipo. A cura: composição.

Especialização Legítima: os Dois Requisitos

  1. Compartilha o DNA essencial do pai
  1. Precisa ser tratada polimorficamente como o tipo base

Sem adicionar nada: “objeto zumbi” — polui a taxonomia sem valor.

Quando Herdar

Por que “o gerenciador usa uma lista, não é uma lista” é o critério certo para decidir entre herança e composição?

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

  • □ Herdar apenas para reaproveitar métodos, sem uma relação “É-UM” real, é um design frágil.
  • □ GerenciadorDeCobrancas extends ListaDeContatos expõe métodos do pai que talvez nunca devessem ser públicos no filho.
  • □ Uma especialização legítima precisa compartilhar o DNA do pai e ser tratada polimorficamente como ele.
  • □ Uma subclasse que não adiciona comportamento nem refina invariantes ainda agrega valor arquitetural por existir.

Quando Herdar — Resposta

Herança vs. composição — Resposta

  • ✔ Herdar apenas para reaproveitar métodos, sem uma relação “É-UM” real, é um design frágil — é o “erro da herança por conveniência”.
  • ✔ GerenciadorDeCobrancas extends ListaDeContatos expõe métodos do pai que talvez nunca devessem ser públicos no filho — é a quebra de encapsulamento citada no exemplo.
  • ✔ Uma especialização legítima precisa compartilhar o DNA do pai e ser tratada polimorficamente como ele — são os dois requisitos cumulativos da especialização legítima.
  • ✗ Uma subclasse que não adiciona comportamento nem refina invariantes ainda agrega valor arquitetural por existir — sem adicionar nada, é um “objeto zumbi” que só polui a taxonomia.

Voltando à pergunta: o critério certo é comportamental — se a classe só precisa dos métodos prontos, é “usa uma” (composição); se precisa herdar o DNA e ser tratada polimorficamente como o tipo base, é “é uma” (herança).

O Vínculo de Sangue: Acoplamento e Invariantes Invisíveis

A Alteração “Inocente”

public void setId(String id) {
    if (!id.startsWith("PUB-")) throw new IllegalArgumentException();
    this.idCobranca = id;
}

Pix já escrevia idCobranca direto (via protected) — quebra em runtime, sem aviso em compilação.

Invariantes Invisíveis: Três Armadilhas

  1. Ordem: pai espera \(A\) antes de \(B\)
  2. Retorno: pai espera “nunca null”
  3. super esquecido: máquina de estado “zumbi”

A Base como Guardiã, e a Classe Abstrata

A Base como Guardiã

private double valor;                          // privado, nao protected
public final void setValor(double v) { ... }    // final, nao pode subverter
protected abstract String executarProcessamento(); // o gancho

Classe Abstrata: a Máquina Semi-Acabada

Como um chassi de carro: rodas, bancos, suspensão — sem motor. new MeioPagamentoBase() nem compila.

Estado (Rígido) vs. Comportamento (Fluido)

public interface Pagavel { String getIdCobranca(); } // Pix decide como representar
protected String logsInternos; // TODO filho carrega isso, use ou nao

Não existe “deserdar” um campo em Java. Herdar estado é compulsório.

Classes Abstratas e Herança de Estado

Por que não existe uma forma de um filho “recusar” um atributo herdado, mas existe @Override para recusar/substituir um método herdado?

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

  • □ Uma classe abstrata pode ter métodos concretos e métodos abstratos ao mesmo tempo.
  • □ O compilador permite instanciar diretamente uma classe abstrata com new, desde que todos os métodos existam.
  • □ Herdar um atributo é uma alocação de memória física compulsória em cada instância do filho.
  • □ Não existe, em Java, uma sintaxe para um filho “recusar” um campo herdado do pai.

Classes Abstratas e Herança de Estado — Resposta

Por que não existe “recusar” um atributo herdado — Resposta

  • ✔ Uma classe abstrata pode ter métodos concretos e métodos abstratos ao mesmo tempo — é a definição de “protocolo de estado parcial”.
  • ✗ O compilador permite instanciar diretamente uma classe abstrata com new, desde que todos os métodos existam — o compilador proíbe new numa classe abstrata, completa ou não.
  • ✔ Herdar um atributo é uma alocação de memória física compulsória em cada instância do filho — é o custo da “herança de estado” descrito nesta aula.
  • ✔ Não existe, em Java, uma sintaxe para um filho “recusar” um campo herdado do pai — diferente de métodos (que aceitam @Override), atributos são herdados sem opção de recusa.

Voltando à pergunta: métodos são comportamento — a JVM despacha por Late Binding, então sobrescrever (@Override) é só apontar para outra implementação. Atributos são alocação física na Heap, decidida a partir do layout da classe; não existe um mecanismo equivalente de “apontar para outro lugar” para um campo.

Template Method

O Esqueleto do Algoritmo

public final String realizarPagamento(double valor) {
    if (!validar(valor)) throw new RuntimeException("...");
    String id = criarCobrancaEspecifica(valor); // o buraco do especialista
    registrarLog(id);
    return id;
}

final: ninguém muda a ordem. abstract: cada filho preenche só seu detalhe.

Inversão de Controle: o Princípio de Hollywood

“Não nos ligue, nós ligamos para você.” O fluxo pertence ao pai — não ao filho.

Ganho: previsibilidade, manutenibilidade, menos chance de erro do especialista. Risco: esqueleto mal projetado vira camisa de força.

Template Method e Inversão de Controle

Se o Pix pudesse sobrescrever realizarPagamento() inteiro (em vez de só criarCobrancaEspecifica()), o que exatamente o sistema perderia?

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

  • □ Se realizarPagamento() não fosse final, uma subclasse poderia pular a validação ou o registro de log.
  • □ O gancho criarCobrancaEspecifica() é o único ponto que cada subclasse precisa conhecer para se especializar.
  • □ No Template Method, é o filho quem decide a ordem em que validação, especialização e log acontecem.
  • □ A Inversão de Controle aqui significa que a base chama o filho, e não o contrário.

Template Method e Inversão de Controle — Resposta

Se o Pix pudesse sobrescrever realizarPagamento() inteiro — Resposta

  • ✔ Se realizarPagamento() não fosse final, uma subclasse poderia pular a validação ou o registro de log — é exatamente o risco de não travar o método com final.
  • ✔ O gancho criarCobrancaEspecifica() é o único ponto que cada subclasse precisa conhecer para se especializar — é o propósito do gancho: isolar o detalhe técnico.
  • ✗ No Template Method, é o filho quem decide a ordem em que validação, especialização e log acontecem — é o pai quem dita a ordem; o filho só preenche a lacuna.
  • ✔ A Inversão de Controle aqui significa que a base chama o filho, e não o contrário — é a essência do Princípio de Hollywood aplicado aqui.

Voltando à pergunta: o sistema perderia a garantia de que validação e log sempre acontecem — cada filho poderia reescrever a sequência inteira, reintroduzindo exatamente os bugs (pular passo, esquecer log) que o Template Method existe para prevenir.

Conclusão

O que Aprendemos

  1. Herança = “É-UM”, incorporação física, o acoplamento mais forte da OO
  2. Classe Base Frágil: alterações inocentes quebram filhos por invariantes invisíveis
  3. Herdar exige DNA compartilhado e necessidade polimórfica — nunca só reuso
  4. Template Method: fluxo travado no pai, ganchos abstratos para o filho

Próxima aula: o Princípio da Substituição de Liskov — quando um filho pode substituir o pai com segurança.

UNICAMP Instituto de Computação