Orientação a objetos

Herança x composição: quando cada uma

Herança = 'é um', acoplada e fixa em compile-time. Composição = 'tem um', trocável em runtime e testável. Prefira composição; herde só em subtipo real e estável.

SOLID: o que cada princípio evita

SRP: um motivo pra mudar. OCP: estender sem editar. LSP: subtipo substitui sem surpresa. ISP: interface pequena. DIP: dependa de abstração.

O que polimorfismo resolve na prática

Mesma chamada, comportamento por tipo. Elimina switch(tipo) repetido: tipo novo = classe nova, sem editar os chamadores.

Encapsulamento não é 'ter getter e setter pra tudo'

Encapsular = esconder estado e expor operações que preservam invariantes. Getter/setter pra tudo vira objeto anêmico sem garantia de consistência.

Injeção de dependência sem framework

Receber dependências de fora (construtor) em vez de fazer `new` dentro. Teste injeta um fake; container só automatiza quando o grafo cresce.

Abstração que vaza (leaky abstraction)

Vaza quando você precisa entender o que ela esconde pra usá-la direito (ORM e N+1, FS de rede e latência). Toda abstração não-trivial vaza; a boa vaza raro e de forma previsível.

Lei de Demeter e o `a.getB().getC().fazer()`

Só fale com vizinhos diretos (this, parâmetros, campos, objetos que você cria). A cadeia longa acopla a três estruturas internas; exponha `pedido.getCidadeDeEntrega()` no lugar.

Cenário: Quadrado herda de Retângulo

Cliente que espera Retangulo assume que setLargura não mexe na altura. Quadrado precisa mexer pra continuar quadrado → quebra o contrato. 'É um' no português não garante substituibilidade.

Objetos imutáveis: o que ganham e o que custam

Ganho: thread-safe sem lock, chave de mapa segura, mais fácil de raciocinar, invariante checado uma vez. Custo: alocação/GC por 'mudança', mais boilerplate. Value objects imutáveis; entidades podem mutar.

Interface x classe abstrata

Interface: contrato sem estado, um tipo implementa várias — capacidades ortogonais. Classe abstrata: implementação + estado comum a subclasses relacionadas, herança única. Contrato → interface; código comum de uma família → abstrata.

Modelo de domínio anêmico

Classes de domínio só com dados+getters/setters e toda a lógica em serviços externos. Antipadrão porque separa regra do dado que ela protege — objeto fica em estado inválido, regra duplica.

Cenário: refatorar uma hierarquia que explodiu

Herança só dá uma dimensão → 2^N classes pra N capacidades. Composição: Personagem tem componentes (movimento, ataque, habilidades) combináveis em runtime. Padrão Strategy / Entity-Component.

"Tell, don't ask"

Diga o que quer que aconteça (`conta.sacar(v)`) em vez de perguntar o estado e decidir fora (`if getSaldo >= v ...`). Mantém a regra junto do dado; consulta pra exibir ainda é ok.