Aula 4 - Material Escrito

Agenda da Aula

• Fundamentos de orientação a objetos e trade-offs de design.
• Mapeamento de UML para código em C#.
• Princípios SOLID (ênfase em SRP e OCP).
• Ciclo Red-Green-Refactor e anti-patterns.
• Boas práticas de TDD para agentes de IA e governança de outputs.

1) Dados x Comportamento

Na aula anterior o foco foi estado (tabelas, colunas, normalização). Nesta aula, o foco passa a ser comportamento (classes, métodos, contratos e invariantes).

struct Aluno { string nome; }
class Aluno { Matricular() { ... } }

Ideia central: objetos combinam dados + comportamento e protegem regras de negócio.

2) Encapsulamento Real (Tell, Don't Ask)

Encapsular não é expor tudo com getter/setter. É proteger invariantes e impedir manipulação indevida do estado.

// Errado (anêmico)
var conta = new Conta();
if (conta.Saldo >= 100) {
  conta.Saldo -= 100;
}

// Certo (comportamento)
var conta = new Conta();
try {
  conta.Sacar(100);
} catch (SaldoInsuficienteException e) { ... }

Lei de Demeter: evitar acoplamento profundo, como pedido.Cliente.Endereco.Cep.

3) Herança vs Composição

• Herança: reuso rápido, mas aumenta acoplamento e risco de violar LSP.
• Composição: maior flexibilidade e testabilidade.

class PatoBorracha : Pato {
  override Voar() { throw new Error(); }
} // Quebrou contrato

class Pato {
  private IVoador _comportamentoVoo;
  public Pato(IVoador v) { _comportamentoVoo = v; }
}

Regra prática: favoreça composição sobre herança.

4) Polimorfismo e DIP

Dependências devem apontar para abstrações, não implementações concretas.

// Acoplado
class PagamentoService {
  private PayPal _paypal = new PayPal();
}

// Desacoplado
class PagamentoService {
  private IPagamento _gateway;
  public PagamentoService(IPagamento gateway) {
    _gateway = gateway;
  }
}

Esse desenho facilita manutenção, testes com mock e evolução do sistema.

5) UML para Comunicação Técnica

• Notação de classe: nome, atributos e métodos.
• Relacionamentos: associação, agregação e composição.
• Objetivo: alinhar equipe sobre estrutura antes da implementação.

6) SOLID (SRP e OCP)

• SRP: uma classe, um motivo para mudar.
• OCP: estender sem editar lógica central (ex.: polimorfismo).

7) TDD na Prática

Ciclo: RED → GREEN → REFACTOR.

[Test]
public void Frete_DeveSerZero_ParaPedidosAcimaDe200() {
  var calc = new FreteCalculadora();
  var valor = calc.Calcular(pedidoTotal: 250);
  Assert.AreEqual(0, valor);
}

public class FreteCalculadora {
  public decimal Calcular(decimal pedidoTotal) {
    if (pedidoTotal > 200) return 0;
    return 20;
  }
}

Primeiro validar comportamento observável; depois refatorar com segurança.

8) Anti-patterns em TDD

• Teste mentiroso (passa sem validar regra real).
• Setup excessivo e alto acoplamento.
• Testar detalhes privados em vez de contrato público.
• Teste lento dependente de rede/banco em cenários unitários.

9) IA + Engenharia: foco em output

Com agentes, o trabalho do engenheiro é cada vez mais governar outputs: ler, interpretar, validar comportamento e gerenciar falhas, sem abandonar leitura crítica de código.

• Definir critérios de qualidade antes da geração.
• Separar agentes por papel (gerar, testar, revisar, refatorar).
• Aprovar somente com evidência (testes, métricas, observabilidade).

// Pipeline orientado a output
RED: teste falha e representa risco real
GREEN: patch minimo para passar
REFACTOR: melhora design sem alterar comportamento
CHECK: cobertura, seguranca, desempenho e regressao

10) Analogia com Engenharia de Chips + ATAM

Na engenharia de semicondutores, ninguém gerencia transistor por transistor. O controle é feito por especificação, simulação, validação e análise de risco de comportamento.

Em software com IA, vale o mesmo princípio: foco em qualidade arquitetural e falhas observáveis.

• ATAM: avaliar trade-offs de confiabilidade, segurança, modificabilidade e observabilidade.
• Modelar cenários de falha para o pipeline de agentes.
• Governar o sistema por evidência, não por intuição.

Referências e Continuidade