Módulo 10: Paradigmas de Programação & Padrões de Projeto • Bloco 1: Paradigmas e Modelos

🔄 Continuação do Fio Condutor (ver Capítulo 01): O mesmo Carrinho de Compras corporativo evolui aqui: enquanto no modelo imperativo as variáveis e arrays ficavam expostos à manipulação externa desordenada, no Paradigma Orientado a Objetos (POO) os dados tornam-se atributos privados protegidos por uma membrana hermética, comunicando-se com o exterior exclusivamente através de métodos públicos e contratos de interface polimórficos.

🗺️ Mapa Conceitual do Capítulo

flowchart TD
    OOP["Paradigma Orientado a Objetos (POO)"]

    subgraph S1["Pilares Conceituais"]
        ENCAP["1. Encapsulamento & Ocultamento\n(Information Hiding de Parnas, Estado Privado)"]
        ABST["2. Abstração e Interfaces\n(Contratos puros desacoplados de implementação)"]
        POLY["3. Polimorfismo Dinâmico\n(Late Binding, Virtual Method Table - vtable)"]
        COMP["4. Composição vs Herança\n(Favoreça Composição: Has-A sobre Is-A)"]
        
        ENCAP --> ABST
        ABST --> POLY
        POLY --> COMP
    end

    subgraph S2["Mecânica de Execução em Baixo Nível"]
        VPTR["Ponteiro vptr no Objeto\n(8 bytes extras no início da instância)"]
        VTABLE["Tabela de Métodos Virtuais (vtable)\n(Array de ponteiros de função indexado pelo compilador)"]
        DISPATCH["Despacho Dinâmico (Dynamic Dispatch)\n(Indireção de ponteiro: call *(vptr + offset))"]
        
        VPTR --> VTABLE
        VTABLE --> DISPATCH
    end

    subgraph S3["Aplicação no Fio Condutor"]
        CARRINHO_OBJ["Carrinho como Agregador Autônomo\n(Protege lista de itens, injeta Estratégia de Frete)"]
    end

    OOP --> S1
    OOP --> S2
    OOP --> S3

    style OOP fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style S1 fill:#e8f5e9,stroke:#388e3c,stroke-width:1px
    style S2 fill:#fff3e0,stroke:#f57c00,stroke-width:1px
    style S3 fill:#e1f5fe,stroke:#0288d1,stroke-width:1px

🏛️ 1. As Origens Filosóficas da Orientação a Objetos

A Orientação a Objetos nasceu em duas ondas históricas complementares:

  1. Simula 67 (Ole-Johan Dahl e Kristen Nygaard, Centro Norueguês de Computação): Criada para modelar simulações físicas de tráfego naval e reatores nucleares, introduziu pioneiramente classes, instâncias, subclasses e procedimentos virtuais.
  2. Smalltalk (Alan Kay, Dan Ingalls e Adele Goldberg, Xerox PARC, década de 1970): Alan Kay formulou a visão canônica: a computação não deveria ser vista como blocos manipulando dados passivos, mas como uma rede biológica de células computacionais independentes (objetos) trocando mensagens assíncronas:

    “I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind… OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” — Alan Kay

🧱 2. Os Quatro Pilares Canônicos da POO

graph LR
    subgraph "Os 4 Pilares da Orientação a Objetos"
        A["1. Abstração<br/>Identidade e essência sem ruído acidental"]
        E["2. Encapsulamento<br/>Estado privado com acesso via métodos"]
        H["3. Herança<br/>Taxonomia e reutilização estrutural (Is-A)"]
        P["4. Polimorfismo<br/>Múltiplas formas de responder à mesma mensagem"]
    end
    style A fill:#e1f5fe,stroke:#03a9f4
    style E fill:#e8f5e9,stroke:#4caf50
    style H fill:#fff3e0,stroke:#ff9800
    style P fill:#fce4ec,stroke:#e91e63

2.1 Abstração e Ocultamento de Informação (Information Hiding)

Formalizado por David Parnas em 1972, o princípio do Ocultamento de Informação dita que um módulo de software deve ocultar suas decisões difíceis de design e estruturas voláteis por trás de uma interface estável. Quem consome um objeto Carrinho não precisa saber se ele armazena seus itens em um vetor contíguo, em uma lista duplamente encadeada ou em uma tabela hash.

2.2 Encapsulamento

Diferente da struct imperativa aberta (onde qualquer código pode executar c->itens[0].preco = -500), o encapsulamento estabelece uma fronteira de proteção:

  • O estado interno é restrito (private / protected).
  • Mutações só ocorrem através de métodos de interface pública que validam rigidamente as Invariantes de Negócio (ex.: impedir que a quantidade de um item seja nula ou negativa).

2.3 Herança e suas Patologias (The Fragile Base Class Problem)

A herança modela relacionamentos taxonômicos estritos do tipo “É-Um” (Is-A). Embora útil em taxonomias de GUI (ex.: Botao extends ComponenteVisual), o uso excessivo de herança em sistemas corporativos gera severos gargalos:

  • Problema da Classe Base Frágil: Uma alteração mínima em um método da superclasse pode quebrar silenciosamente subclasses em dezenas de módulos distintos.
  • Explosão Combinatória: Subclasses rígidas não se combinam dinamicamente (ex.: CarrinhoComFreteExpresso, CarrinhoComFreteEconomicoComDescontoVIP etc.).

2.4 Polimorfismo e Despacho Dinâmico (Dynamic Dispatch)

O Polimorfismo permite tratar objetos de diferentes classes derivadas através de uma interface ou classe base comum. Ele divide-se em:

  • Polimorfismo Estático (Ad-hoc / Paramétrico): Resolvido em tempo de compilação sem custo de runtime (sobrecarga de métodos e templates/generics).
  • Polimorfismo Dinâmico (Subtipagem): A decisão exata de qual função executar é adiada para o tempo de execução (Late Binding), permitindo que o código se adapte a novas classes sem ser recompilado.

⚙️ 3. A Física da POO: Como Funciona a Virtual Table (vtable)

Linguagens compiladas como C++, Java e Rust (trait objects) implementam o polimorfismo dinâmico através de uma estrutura física denominada Vtable (Virtual Method Table):

graph LR
    subgraph "Instância do Objeto no Heap"
        OBJ["Objeto: FreteExpresso<br/>[vptr: 0x7FFF0001]<br/>[Atributo: taxa_base = 25.0]"]
    end
    subgraph "Vtable na Memória (Read-Only Data)"
        VTABLE["Vtable de FreteExpresso<br/>[0]: &FreteExpresso::calcular<br/>[1]: &FreteExpresso::descrever"]
    end
    subgraph "Código Binário na CPU"
        CODE["Instrução ASM:<br/>FreteExpresso::calcular(peso)"]
    end
    OBJ -->|"Ponteiro vptr (8 bytes)"| VTABLE
    VTABLE --> CODE
  1. Quando uma classe declara métodos virtuais ou implementa uma interface, o compilador aloca silenciosamente um ponteiro oculto de 8 bytes no início de cada instância: o vptr.
  2. O vptr aponta para uma tabela global de ponteiros de funções em memória estática (vtable).
  3. Ao invocar calculadora->calcular(peso), a CPU executa: \(\text{CALL} \quad *(\text{objeto}\to\text{vptr}[\text{OFFSET\_CALCULAR}])\)
  4. Custo Computacional: Exige exatamente 1 ciclo de indireção de memória adicional, um preço mínimo a pagar pela extensibilidade aberta do software.

⚖️ 4. O Primeiro Princípio do Gang of Four: “Favoreça Composição sobre Herança”

No clássico livro Design Patterns (GoF, 1994), Erich Gamma e seus coautores estabeleceram a regra de ouro que transformou a arquitetura de software moderna:

classDiagram
    class CalculadoraDeFrete {
        <<interface>>
        +calcular(peso) double
    }
    class FreteExpresso {
        +calcular(peso) double
    }
    class FreteEconomico {
        +calcular(peso) double
    }
    class CarrinhoDeCompras {
        -itens: List~Item~
        -freteStrategy: CalculadoraDeFrete
        +adicionarItem(item) void
        +calcularTotal() double
    }

    CarrinhoDeCompras *-- CalculadoraDeFrete : Composição Flexível (Has-A)
    FreteExpresso ..|> CalculadoraDeFrete : Implementação Polimórfica
    FreteEconomico ..|> CalculadoraDeFrete : Implementação Polimórfica
  • Herança (Is-A): Cria acoplamento estático engessado em tempo de compilação.
  • Composição (Has-A): O Carrinho não é um tipo de frete; ele tem uma referência para um componente de frete. A estratégia pode ser substituída em tempo de execução via injeção de dependência (setCalculadoraFrete), permitindo testes com mocks e evolução modular.

🛒 5. Fio Condutor: O Carrinho de Compras em POO com Composição

Vejamos como o mesmo problema do Capítulo 01 é modelado com excelência orientada a objetos em Python:

from abc import ABC, abstractmethod
from typing import List

# 1. Interface e Contrato Polimórfico
class CalculadoraFrete(ABC):
    @abstractmethod
    def calcular_frete(self, peso_kg: float) -> float:
        pass

class FreteExpresso(CalculadoraFrete):
    def calcular_frete(self, peso_kg: float) -> float:
        return 35.0 + (peso_kg * 4.5)

class FreteEconomico(CalculadoraFrete):
    def calcular_frete(self, peso_kg: float) -> float:
        return 15.0 + (peso_kg * 1.8)

# 2. Entidade Item com Encapsulamento
class Item:
    def __init__(self, id_item: str, nome: str, preco: float, qtd: int, peso_unit: float):
        if preco < 0 or qtd <= 0:
            raise ValueError("Preço e quantidade devem ser estritamente positivos!")
        self._id = id_item
        self._nome = nome
        self._preco = preco
        self._quantidade = qtd
        self._peso_unit = peso_unit

    @property
    def subtotal(self) -> float:
        return self._preco * self._quantidade

    @property
    def peso_total(self) -> float:
        return self._peso_unit * self._quantidade

    @property
    def nome(self) -> str:
        return self._nome

# 3. Agregador Carrinho: Composição e Proteção de Estado
class CarrinhoDeCompras:
    def __init__(self, estrategia_frete: CalculadoraFrete):
        self._itens: List[Item] = []
        self._estrategia_frete = estrategia_frete
        self._desconto_cupom = 0.0

    def adicionar_item(self, item: Item) -> None:
        self._itens.append(item)

    def aplicar_cupom(self, valor: float) -> None:
        if valor < 0:
            raise ValueError("O desconto não pode ser negativo.")
        self._desconto_cupom = valor

    def definir_estrategia_frete(self, nova_estrategia: CalculadoraFrete) -> None:
        """Permite substituir o algoritmo de frete em tempo de execução!"""
        self._estrategia_frete = nova_estrategia

    def calcular_resumo(self) -> dict:
        subtotal = sum(i.subtotal for i in self._itens)
        peso_total = sum(i.peso_total for i in self._itens)
        custo_frete = self._estrategia_frete.calcular_frete(peso_total)
        total_liquido = max(0.0, subtotal + custo_frete - self._desconto_cupom)

        return {
            "subtotal": subtotal,
            "peso_kg": peso_total,
            "frete": custo_frete,
            "desconto": self._desconto_cupom,
            "total_liquido": total_liquido
        }

📊 6. Matriz Comparativa: Paradigma Estruturado vs Orientado a Objetos

Dimensão de Comparação Paradigma Estruturado (Cap. 01) Paradigma Orientado a Objetos (Cap. 02)
Unidade Básica de Construção Procedimentos / Funções soltas Objetos (comportamento + dados coesos)
Proteção de Estado Ausente (structs públicas e manipuláveis) Hermética (privada com interfaces públicas)
Flexibilidade de Extensão Exige alterar switch/case e structs existentes Aberto para extensão via polimorfismo dinâmico
Relação entre Componentes Funções chamam funções com ponteiros Objetos colaboram através de envio de mensagens
Tratamento de Dados de Negócio Dados são estruturas passivas sem inteligência Objetos são agentes ativos responsáveis por suas regras