Anti-padrões são "soluções" recorrentes que parecem razoáveis, mas degradam um projeto. Os mais comuns em OOP são o God Object, hierarquias de herança profundas e o Anemic Domain Model.
Uma classe que sabe e faz demais — violando Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Cada nível se acopla a todos os ancestrais; uma mudança no topo se propaga em todos os lugares (classe base frágil). Solução: achate com composição; prefira capacidades "has-a" sobre cadeias "is-a" profundas.
Objetos que são apenas sacos de getters/setters com toda a lógica vivendo em outro lugar — OOP apenas de nome.
// ANEMIC: data with no behavior; rules live in a separate "service"
class Order { List<Item> items; double total; /* only getters/setters */ }
class OrderService { double calcTotal(Order o) { ... } } // logic exiled
// RICH: behavior lives with the data it operates on
class Order {
private List<Item> items;
double total() { return items.stream().mapToDouble(Item::price).sum(); }
}
→ Yo-yo problem (jumping up/down a deep hierarchy to follow logic)
→ Circular deps (A needs B needs A)
→ Feature envy (a method that mostly uses another class's data)
Anti-padrões são como as boas intenções apodrecem: um God Object geralmente começa como um pequeno auxiliar, um modelo anêmico como "apenas DTOs", depois se ossifica.
Nomeá-los dá aos times um vocabulário compartilhado de aviso antecipado em revisão de código, e cada anti-padrão aponta diretamente para o princípio (SRP, composição, encapsulamento) que o corrige.