Herança e Polimorfismo

No artigo Classes e Objetos: os fundamentos da Orientação a Objetos criamos classes independentes. Mas e quando duas classes compartilham características comuns? Reescrever o mesmo código em cada uma viola um princípio fundamental do desenvolvimento de software: DRY — Don't Repeat Yourself. Herança resolve esse problema permitindo que uma classe herde atributos e métodos de outra, e polimorfismo permite que objetos de tipos diferentes respondam ao mesmo comando de formas distintas.

Herança Simples

Uma classe filha herda tudo da classe pai e pode estender ou modificar esse comportamento:

class Animal:
    def __init__(self, nome, idade):
        self.nome  = nome
        self.idade = idade

    def apresentar(self):
        return f"Eu sou {self.nome} e tenho {self.idade} ano(s)."

    def emitir_som(self):
        return "..."


class Cachorro(Animal):
    def emitir_som(self):
        return "Au au!"

    def buscar(self, objeto):
        return f"{self.nome} buscou o {objeto}!"


class Gato(Animal):
    def emitir_som(self):
        return "Miau!"

    def arranhar(self):
        return f"{self.nome} arranhou o sofá."


rex    = Cachorro("Rex",    3)
mimi   = Gato("Mimi",   5)

print(rex.apresentar())     # Eu sou Rex e tenho 3 ano(s).
print(rex.emitir_som())     # Au au!
print(rex.buscar("graveto")) # Rex buscou o graveto!
print(mimi.emitir_som())    # Miau!

Cachorro e Gato herdam apresentar() de Animal sem precisar reescrevê-lo. Cada uma sobrescreve emitir_som() com seu próprio comportamento — isso é sobrescrita de método (method overriding).

A Função super()

super() permite chamar métodos da classe pai a partir da classe filha — essencial para estender o construtor:

class Veiculo:
    def __init__(self, marca, modelo, ano):
        self.marca  = marca
        self.modelo = modelo
        self.ano    = ano

    def descricao(self):
        return f"{self.ano} {self.marca} {self.modelo}"


class Carro(Veiculo):
    def __init__(self, marca, modelo, ano, portas):
        super().__init__(marca, modelo, ano)   # chama __init__ do pai
        self.portas = portas

    def descricao(self):
        base = super().descricao()             # reutiliza o método do pai
        return f"{base} ({self.portas} portas)"


class CarroEletrico(Carro):
    def __init__(self, marca, modelo, ano, portas, autonomia_km):
        super().__init__(marca, modelo, ano, portas)
        self.autonomia_km = autonomia_km

    def descricao(self):
        base = super().descricao()
        return f"{base} — Elétrico, {self.autonomia_km}km de autonomia"


civic = Carro("Honda", "Civic", 2023, 4)
model3 = CarroEletrico("Tesla", "Model 3", 2024, 4, 560)

print(civic.descricao())
# 2023 Honda Civic (4 portas)

print(model3.descricao())
# 2024 Tesla Model 3 (4 portas) — Elétrico, 560km de autonomia

Polimorfismo

Polimorfismo significa "muitas formas". Em Python, objetos de classes diferentes podem ser tratados de forma uniforme se implementarem os mesmos métodos:

class Circulo:
    def __init__(self, raio):
        self.raio = raio

    def area(self):
        import math
        return math.pi * self.raio ** 2

    def perimetro(self):
        import math
        return 2 * math.pi * self.raio


class Retangulo:
    def __init__(self, largura, altura):
        self.largura = largura
        self.altura  = altura

    def area(self):
        return self.largura * self.altura

    def perimetro(self):
        return 2 * (self.largura + self.altura)


class Triangulo:
    def __init__(self, base, altura, lado_a, lado_b, lado_c):
        self.base    = base
        self.altura  = altura
        self.lados   = (lado_a, lado_b, lado_c)

    def area(self):
        return (self.base * self.altura) / 2

    def perimetro(self):
        return sum(self.lados)


# Polimorfismo em ação — mesma interface, comportamentos diferentes
formas = [
    Circulo(5),
    Retangulo(4, 6),
    Triangulo(3, 4, 3, 4, 5),
]

for forma in formas:
    nome = type(forma).__name__
    print(f"{nome:12} | Área: {forma.area():7.2f} | Perímetro: {forma.perimetro():.2f}")

Saída:

Circulo      | Área:   78.54 | Perímetro: 31.42
Retangulo    | Área:   24.00 | Perímetro: 20.00
Triangulo    | Área:    6.00 | Perímetro: 12.00

Nenhuma das classes herda da outra — mesmo assim podemos tratá-las uniformemente. Isso é o duck typing do Python: se o objeto tem o método area(), ele pode ser usado onde area() for chamado. "Se anda como pato e grasna como pato, é um pato."

Classes Abstratas

Quando você quer garantir que subclasses implementem determinados métodos, use o módulo abc:

from abc import ABC, abstractmethod

class Forma(ABC):
    """Classe base abstrata — não pode ser instanciada diretamente.

    A checagem acontece na INSTANCIAÇÃO, não na definição: uma subclasse
    que esqueça de implementar um método abstrato é criada sem erro, e só
    levanta TypeError quando alguém tenta construir um objeto dela.
    """

    @abstractmethod
    def area(self):
        """Toda forma deve implementar area()."""
        pass

    @abstractmethod
    def perimetro(self):
        """Toda forma deve implementar perimetro()."""
        pass

    def descricao(self):
        """Método concreto — herdado por todas as subclasses."""
        return (f"{type(self).__name__}: "
                f"área={self.area():.2f}, "
                f"perímetro={self.perimetro():.2f}")


class Quadrado(Forma):
    def __init__(self, lado):
        self.lado = lado

    def area(self):
        return self.lado ** 2

    def perimetro(self):
        return 4 * self.lado


class Hexagono(Forma):
    def __init__(self, lado):
        self.lado = lado

    def area(self):
        import math
        return (3 * math.sqrt(3) / 2) * self.lado ** 2

    def perimetro(self):
        return 6 * self.lado


# Forma()     # TypeError — não pode instanciar classe abstrata
q = Quadrado(5)
h = Hexagono(4)

print(q.descricao())  # Quadrado: área=25.00, perímetro=20.00
print(h.descricao())  # Hexagono: área=41.57, perímetro=24.00

Herança Múltipla e MRO

Python suporta herança múltipla — uma classe pode herdar de várias classes ao mesmo tempo:

class Nadador:
    def nadar(self):
        return f"{self.nome} está nadando."

class Corredor:
    def correr(self):
        return f"{self.nome} está correndo."

class Ciclista:
    def pedalar(self):
        return f"{self.nome} está pedalando."

class Triatleta(Nadador, Corredor, Ciclista):
    def __init__(self, nome):
        self.nome = nome

    def competir(self):
        return [self.nadar(), self.pedalar(), self.correr()]


atleta = Triatleta("Carlos")
for atividade in atleta.competir():
    print(atividade)

# Carlos está nadando.
# Carlos está pedalando.
# Carlos está correndo.

Quando há ambiguidade sobre qual método usar, Python segue o MRO — Method Resolution Order, calculado pelo algoritmo C3:

print(Triatleta.__mro__)
# (<class '__main__.Triatleta'>, <class '__main__.Nadador'>,
#  <class '__main__.Corredor'>, <class '__main__.Ciclista'>,
#  <class 'object'>)

Só que no exemplo acima o MRO não decide nada: Nadador, Corredor e Ciclista não têm método algum em comum, então não há ambiguidade a resolver. A ordem importa quando duas classes da hierarquia definem o mesmo método — a situação que se chama diamante, porque dois caminhos partem de uma base comum e voltam a se encontrar:

class A:
    def quem(self): return "A"

class B(A):
    def quem(self): return "B -> " + super().quem()

class C(A):
    def quem(self): return "C -> " + super().quem()

class D(B, C):
    pass

print(D().quem())                       # B -> C -> A
print([k.__name__ for k in D.__mro__])  # ['D', 'B', 'C', 'A', 'object']

Este é o ponto que quase todo material erra ao explicar super(): lendo a classe B isoladamente, é natural concluir que super().quem() chama A.quem, já que B herda de A. Não é o que acontece. O super() não significa a classe pai; significa o próximo da fila do MRO do objeto em questão. Quando quem está sendo usado é um D, o próximo depois de B é C, e por isso A é visitada uma única vez, no fim. É essa propriedade que faz a herança múltipla funcionar de forma cooperativa em Python, e é por isso que um método que participa de uma hierarquia deve chamar super() mesmo parecendo não ter para onde ir.

O algoritmo que calcula essa ordem, o C3, também sabe recusar o impossível. Se duas bases exigirem ordens contraditórias, o erro aparece na definição da classe, não no uso:

class X(B, C): pass
class Y(C, B): pass
class Z(X, Y): pass
# TypeError: Cannot create a consistent method resolution order (MRO)
# for bases B, C

Vale notar ainda que os três papéis do exemplo do triatleta usam self.nome sem nunca declará-lo — eles contam com um __init__ que só existe na classe de baixo. Instanciar Nadador() sozinho e chamar nadar() levanta AttributeError. É o padrão mixin, legítimo e muito usado, mas com um contrato implícito que precisa estar documentado: a classe não funciona sozinha, e espera que quem a combine forneça certos atributos.

Verificando Herança

rex = Cachorro("Rex", 3)

print(isinstance(rex, Cachorro))  # True
print(isinstance(rex, Animal))    # True — herança
print(isinstance(rex, Gato))      # False

print(issubclass(Cachorro, Animal))  # True
print(issubclass(Gato, Cachorro))    # False

Exemplo Completo: Sistema de Pagamentos

from abc import ABC, abstractmethod

class MetodoPagamento(ABC):
    def __init__(self, titular):
        self.titular = titular

    @abstractmethod
    def processar(self, valor):
        pass

    @abstractmethod
    def descricao(self):
        pass

    def recibo(self, valor, status):
        # recebe o status pronto: emitir recibo não pode processar pagamento
        return (f"Recibo — {self.titular}\n"
                f"Método: {self.descricao()}\n"
                f"Valor:  R${valor:.2f}\n"
                f"Status: {status}")


class CartaoCredito(MetodoPagamento):
    def __init__(self, titular, numero, limite):
        super().__init__(titular)
        self.numero = f"**** **** **** {numero[-4:]}"
        self.limite = limite
        self._gasto = 0

    def processar(self, valor):
        if self._gasto + valor > self.limite:
            return "RECUSADO — limite insuficiente"
        self._gasto += valor
        return "APROVADO"

    def descricao(self):
        return f"Cartão de Crédito {self.numero}"


class Pix(MetodoPagamento):
    def __init__(self, titular, chave):
        super().__init__(titular)
        self.chave = chave

    def processar(self, valor):
        return "APROVADO — transferência instantânea"

    def descricao(self):
        return f"Pix ({self.chave})"


class Boleto(MetodoPagamento):
    def __init__(self, titular):
        super().__init__(titular)

    def processar(self, valor):
        return "PENDENTE — aguardando compensação"

    def descricao(self):
        return "Boleto Bancário"


pagamentos = [
    CartaoCredito("Ana",    "1234567890123456", 2000),
    Pix("Bruno",  "bruno@email.com"),
    Boleto("Carla"),
]

valores = [150.00, 89.90, 320.00]

for metodo, valor in zip(pagamentos, valores):
    status = metodo.processar(valor)     # cobra uma vez, aqui
    print(metodo.recibo(valor, status))  # e só formata
    print("-" * 40)

A separação acima não é preciosismo. Na versão natural de escrever essa classe, o recibo monta o texto chamando self.processar(valor) lá dentro — e como processar do cartão soma ao _gasto, emitir o recibo cobra o cartão. Reimprimir, mandar por e-mail ou registrar no log, cada um custa uma cobrança nova:

c = CartaoCredito("Ana", "1234567890123456", 2000)

c.recibo(150.00)   # APROVADO   — _gasto = 150
c.recibo(150.00)   # APROVADO   — _gasto = 300, cobrou de novo
c.recibo(1800.00)  # RECUSADO   — o limite estourou por causa da reimpressão

A regra que evita a classe inteira desse problema: um método ou consulta ou altera, nunca as duas coisas. Quem tem nome de consulta — recibo, descricao, total, qualquer @property — deve poder ser chamado dez vezes seguidas sem mudar nada. Quando o nome promete uma coisa e o corpo faz outra, o defeito não é encontrável por leitura de quem chama, porque quem chama está confiando no nome.

Herança e polimorfismo resolvem problemas distintos, e em Python o segundo raramente depende do primeiro. A herança serve para reaproveitar implementação, e é uma ferramenta a usar com parcimônia: cada nível novo amarra a filha à forma interna da mãe. O polimorfismo, esse sim, é o que se busca o tempo todo — e o duck typing o entrega sem hierarquia nenhuma, bastando que os objetos respondam aos mesmos métodos, como as três formas geométricas deste artigo, que não herdam umas das outras e ainda assim são tratadas pelo mesmo laço. Quando o contrato precisa ser garantido em vez de combinado, o ABC com @abstractmethod obriga a implementação — lembrando que a checagem ocorre na instanciação, não na definição da subclasse.

Duas correções de entendimento ficam deste artigo. O super() não significa a classe pai, e sim o próximo da fila do MRO do objeto: numa hierarquia em diamante, o super() escrito dentro de uma classe pode levar a uma irmã dela, não à mãe, e é essa propriedade que faz a herança múltipla funcionar de forma cooperativa. E um método que consulta não pode alterar: o recibo do exemplo de pagamentos processava a cobrança ao montar o texto, de modo que reimprimir um recibo cobrava o cartão outra vez — defeito impossível de achar lendo quem chama, porque quem chama está confiando no nome do método.

Fontes e leituras recomendadas

• Herança — documentação oficial — https://docs.python.org/3/tutorial/classes.html#inheritance
• Módulo abc — classes abstratas — https://docs.python.org/3/library/abc.html
• MRO e algoritmo C3 — https://docs.python.org/3/howto/mro.html
• Duck typing e protocolos — https://docs.python.org/3/glossary.html#term-duck-typing
• RAMALHO, Luciano. Fluent Python. 2. ed. O'Reilly Media, 2022. Cap. 14 — herança, para o bem e para o mal.
• PHILLIPS, Dusty; LOTT, Steven F. Python Object-Oriented Programming. 4. ed. Packt, 2021. Cap. 4–5 — herança e polimorfismo com exemplos avançados.
• GAMMA, Erich et al. Design Patterns. Addison-Wesley, 1994. — a base teórica por trás do uso de herança e polimorfismo em sistemas reais.

Exercícios

Exercício 1

Um sistema de faturamento tem um método fatura(valor) que monta o texto da fatura e, ao montá-lo, consulta self.processar(valor) para incluir o status. O time de suporte reclama que alguns clientes foram cobrados duas e três vezes, sempre os que ligaram pedindo segunda via. Explique a relação e enuncie a regra de projeto que evita esta classe inteira de defeitos.

Exercício 2

Dado o código abaixo, diga o que D().quem() imprime e justifique. A resposta intuitiva — que super() dentro de B chama A, já que B herda de A — está errada.

class A:
    def quem(self): return "A"

class B(A):
    def quem(self): return "B -> " + super().quem()

class C(A):
    def quem(self): return "C -> " + super().quem()

class D(B, C):
    pass

Exercício 3

Uma classe base define @abstractmethod def salvar(self). Um desenvolvedor cria uma subclasse e esquece de implementar o método. O código passa na importação, passa na revisão, passa no linter, e só quebra em produção. Explique em que momento a verificação acontece e que prática de teste teria pegado isso antes.

Exercício 4

Um projeto define class Nadador: com o método nadar que usa self.nome, sem que a classe declare esse atributo em lugar nenhum. Funciona porque só é usada como base de Triatleta, que define self.nome no construtor. Um colega tenta reaproveitar Nadador sozinho em outro módulo e recebe AttributeError. Avalie o projeto original e diga como tornar o contrato explícito.

Exercício 5

As três formas geométricas deste artigo — Circulo, Retangulo e Triangulo — não herdam de nenhuma classe comum e ainda assim são percorridas pelo mesmo laço. Explique por que isso funciona, e discuta quando vale a pena introduzir uma classe base abstrata que elas passem a herdar, e quando isso é apenas cerimônia.