Los anti-patterns son "soluciones" recurrentes que se ven razonables pero degradan un diseño. Los más comunes en OOP son el God Object, las jerarquías de herencia profundas y el Anemic Domain Model.
Una clase que sabe y hace demasiado — viola Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Cada nivel se acopla a todos los antepasados; un cambio cerca de la parte superior se propaga por todas partes (fragile base class). Solución: aplanar con composition; preferir capacidades "has-a" sobre cadenas "is-a" profundas.
Objetos que son solo bolsas de getters/setters con toda la lógica viviendo en otro lugar — OOP solo de nombre.
// 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)
Los anti-patterns son cómo se pudren las buenas intenciones: un God Object generalmente comienza como un pequeño helper, un modelo anémico como "solo DTOs", luego se osifica.
Nombrarlos les da a los equipos un vocabulario compartido de alerta temprana en revisión de código, y cada anti-pattern señala directamente al principio (SRP, composition, encapsulation) que lo soluciona.