Gli anti-pattern sono "soluzioni" ricorrenti che sembrano ragionevoli ma degradano un design. I più comuni in OOP sono il God Object, le gerarchie di eredità profonde e il Anemic Domain Model.
Una classe che sa e fa troppo — violando la Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Ogni livello si accoppia a tutti gli antenati; una modifica vicino alla cima si propaga ovunque (fragile base class). Fix: appiattire con la composition; preferire le capacità "has-a" alle catene profonde "is-a".
Oggetti che sono solo sacchi di getters/setters con tutta la logica altrove — OOP solo di 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)
Gli anti-pattern sono come le buone intenzioni marciscono: un God Object di solito inizia come un piccolo helper, un modello anemico come "solo DTO", poi si ossifica.
Nominarli dà ai team un vocabolario di preallarme condiviso nella code review, e ogni anti-pattern punta direttamente al principio (SRP, composition, encapsulation) che lo risolve.