Composição de Sistemas: Contratos e Estabilidade

Aula 3 — Programação Orientada a Objetos

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

2026-08-30

Proposta da Aula

Até aqui: anatomia de uma peça isolada (Aulas 1–2).

A partir de agora: como as peças se conectam — a Orientação a Objetos como design de comunicações.

Roteiro: colaboração → interface vs. implementação → Lei de Demeter → Plug-and-Play.

Especialistas Colaborando: Produto, ItemCarrinho, Carrinho

Cada Classe, um Especialista

public class Produto {
    private double precoBase;
    public double getPreco() { return this.precoBase; }
}

public class ItemCarrinho {
    private Produto produto;
    public double subtotal() { return produto.getPreco() * quantidade; } // pergunta, nao acessa
}

O Carrinho: Orquestrador, Não Calculador

public double calcularTotal() {
    double total = 0;
    for (ItemCarrinho item : itens) total += item.subtotal(); // delegacao
    return total;
}

Carrinho não sabe de preço nem imposto — só confia no contrato subtotal().

Dividir em especialistas evita Objetos Deus e permite testar cada peça isolada.

Interface vs. Implementação: a Fronteira da Estabilidade

O Cliente Confia na Caixa Preta

public class Compra {
    public void processar(CartaoDeCredito cartao) {
        ValidadorFinanceiro v = new ValidadorFinanceiro();
        if (v.isValido(cartao)) { /* ... */ } // nao pergunta COMO
    }
}

O “Como” Fica Escondido

public class ValidadorFinanceiro {
    public boolean isValido(CartaoDeCredito c) {         // O QUE (publico)
        return verificarLuhn(c) && consultarGateway(c);
    }
    private boolean verificarLuhn(CartaoDeCredito c) {...}   // COMO (privado)
    private boolean consultarGateway(CartaoDeCredito c) {...}
}

Trocar o gateway por REST ou gRPC: Compra nem percebe.

Encapsulamento e Evolução sem Regressão

V1: A Regra Simples

public double calcularPrecoDeVenda() {
    return this.precoCusto * 1.8;
}

V2: A Regra Ficou Complexa — Contrato Igual

public double calcularPrecoDeVenda() {
    if (this.precoCusto > 1000.0) return this.precoCusto * 1.75;
    return this.precoCusto * 1.90;
}

Mesma assinatura pública → zero impacto em quem chama calcularPrecoDeVenda().

Se Carrinho tivesse um getter para precoCusto e calculasse a margem por fora, o que exatamente quebraria quando a regra de margem mudasse?

Escreva sua resposta e compare com um colega antes de avançar (2 min). Para ajudar, julgue V ou F nos 4 itens abaixo — a questão só conta se acertar todos:

  • □ A interface define o “O Quê” um objeto promete fazer; a implementação é o “Como”, escondido do cliente.
  • □ Trocar a implementação interna de um método, mantendo sua assinatura, não deveria exigir mudanças no código cliente.
  • □ ItemCarrinho.subtotal() deveria ler diretamente o atributo precoBase de Produto para ser mais eficiente.
  • □ Encapsular calcularPrecoDeVenda() dentro de Produto centraliza a política de margem num único lugar do sistema.

Interface, Implementação e Evolução — Resposta

Dica

  • ✔ A interface define o “O Quê” um objeto promete fazer; a implementação é o “Como”, escondido do cliente — é a definição central desta aula.
  • ✔ Trocar a implementação interna de um método, mantendo sua assinatura, não deveria exigir mudanças no código cliente — é exatamente o benefício da estabilidade de contrato.
  • ✗ ItemCarrinho.subtotal() deveria ler diretamente o atributo precoBase de Produto para ser mais eficiente — isso violaria o encapsulamento; subtotal() deve perguntar via getPreco().
  • ✔ Encapsular calcularPrecoDeVenda() dentro de Produto centraliza a política de margem num único lugar do sistema — é o mesmo argumento do Bloco 3, mudança de regra sem efeito cascata.

Voltando à pergunta: se Carrinho tivesse copiado precoCusto para calcular a margem por fora, a lógica de margem ficaria duplicada em toda classe que precisa de um preço — mudar a regra exigiria caçar e atualizar cada cópia, exatamente o efeito cascata que a caixa preta de Produto evita.

A Lei de Demeter

O Naufrágio de Código (Train Wreck)

double saldo = pedido.getCliente().getCarteira().getSaldo(); // violacao

Não é o número de pontos — é a fronteira invadida. Se Carteira mudar, Checkout quebra, mesmo sem relação direta com ela.

A Cura: Delegação em Cadeia

if (pedido.clientePodePagar()) { ... }               // Checkout fala so com Pedido

public boolean clientePodePagar() {                  // Pedido delega ao Cliente
    return this.cliente.temSaldoSuficiente(this.total);
}

Checkout fica cego para a existência de uma Carteira. Trocar por ApplePay: zero impacto.

Por que “número de pontos na linha” é um jeito ruim de explicar a Lei de Demeter, e “fronteira invadida” é melhor?

Escreva sua resposta e compare com um colega antes de avançar (2 min). Para ajudar, julgue V ou F nos 4 itens abaixo — a questão só conta se acertar todos:

  • □ A Lei de Demeter recomenda que um objeto interaja apenas com seus “amigos próximos”.
  • □ pedido.getCliente().getCarteira().getSaldo() é um exemplo saudável de reuso de getters.
  • □ Feature Envy é o sintoma de uma classe mais interessada nos dados de outra do que nos próprios.
  • □ A cura técnica para o naufrágio de código é criar métodos de delegação, como pedido.clientePodePagar().

Lei de Demeter e Tell, Don’t Ask — Resposta

Dica

  • ✔ A Lei de Demeter recomenda que um objeto interaja apenas com seus “amigos próximos” — é a própria definição da lei.
  • ✗ pedido.getCliente().getCarteira().getSaldo() é um exemplo saudável de reuso de getters — é o exemplo clássico de violação (train wreck).
  • ✔ Feature Envy é o sintoma de uma classe mais interessada nos dados de outra do que nos próprios — é a definição do code smell.
  • ✔ A cura técnica para o naufrágio de código é criar métodos de delegação, como pedido.clientePodePagar() — delegação em cadeia é exatamente a solução apresentada.

Voltando à pergunta: contar pontos falha porque encadear getters de objetos que já são “amigos” (por exemplo, uma fluent interface de configuração) não viola nada, e uma única navegação até um objeto que não é amigo direto já é problema; “fronteira invadida” aponta a causa real — depender da estrutura interna de um vizinho que não deveria ser alcançado diretamente.

Programando para Abstrações: Sistemas Plug-and-Play

O Contrato Pagavel

public interface Pagavel { boolean isPagamentoValido(); }
public class Boleto implements Pagavel { ... }
public class CartaoDeCredito implements Pagavel { ... }

Checkout Aceita Qualquer Pagavel

public void finalizar(Pagavel metodo) {
    if (metodo.isPagamentoValido()) System.out.println("Transacao concluida!");
}

Amanhã surge o Pix → só Pix implements Pagavel. Checkout não muda.

O Erro de Tipagem como Diagnóstico

public void processar(CartaoDeCredito cartao) { ... }
processar(meuBoleto); // erro: "Boleto cannot be converted to Cartao"

O erro revela que o sistema “sabe demais”: exige identidade específica, não capacidade funcional.

Se Checkout.finalizar recebesse CartaoDeCredito em vez de Pagavel, o que exatamente o erro de compilação de um novo Pix estaria diagnosticando sobre o design?

Escreva sua resposta e compare com um colega antes de avançar (2 min). Para ajudar, julgue V ou F nos 4 itens abaixo — a questão só conta se acertar todos:

  • □ Checkout.finalizar(Pagavel metodo) aceita qualquer classe futura que implemente Pagavel, sem recompilação.
  • □ Um erro de compilação ao tentar passar Boleto onde se espera CartaoDeCredito é sempre culpa do compilador, não do design.
  • □ Programar para o tipo concreto (CartaoDeCredito) em vez da interface (Pagavel) aumenta o acoplamento do sistema.
  • □ Uma interface bem desenhada funciona como um “encaixe universal”, indiferente à identidade concreta de quem a implementa.

Programando para Abstrações — Resposta

Dica

  • ✔ Checkout.finalizar(Pagavel metodo) aceita qualquer classe futura que implemente Pagavel, sem recompilação — é o próprio benefício do Plug-and-Play.
  • ✗ Um erro de compilação ao tentar passar Boleto onde se espera CartaoDeCredito é sempre culpa do compilador, não do design — é um diagnóstico de acoplamento forte no design, não um bug do compilador.
  • ✔ Programar para o tipo concreto (CartaoDeCredito) em vez da interface (Pagavel) aumenta o acoplamento do sistema — exigir a classe concreta é o próprio sintoma de acoplamento forte.
  • ✔ Uma interface bem desenhada funciona como um “encaixe universal”, indiferente à identidade concreta de quem a implementa — é a analogia do “padrão USB-C” desta seção.

Voltando à pergunta: o erro de compilação diagnostica que o sistema amarrou uma operação de negócio a uma identidade concreta específica em vez de a uma capacidade — é o sintoma exato de acoplamento forte que a Interface resolve, elevando o parâmetro para o nível de abstração certo.

Conclusão

O que Aprendemos

  1. Sistemas são redes de colaboradores, não amontoados de classes
  2. Interface (O Quê, estável) vs. Implementação (Como, volátil)
  3. Lei de Demeter: fale só com amigos próximos
  4. Programar para interfaces → sistemas Plug-and-Play

Próxima aula: decompor uma única classe que faz coisas demais — o Princípio da Responsabilidade Única.

UNICAMP Instituto de Computação