Anti-patterns zijn terugkerende "oplossingen" die redelijk lijken maar een ontwerp verslechteren. De meest voorkomende in OOP zijn de God Object, diepe overervingshiërarchieën en het Anemic Domain Model.
Een klasse die te veel weet en te veel doet — schendt Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Elk niveau koppelt aan alle voorouders; een wijziging bovenaan verspreidt zich overal (fragile base class). Oplossing: plat maken met compositie; geef voorkeur aan "has-a" mogelijkheden boven diepe "is-a" ketens.
Objecten die slechts zakken getters/setters zijn met alle logica elders — OOP alleen in naam.
// 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-patterns zijn hoe goede bedoelingen rotten: een God Object begint meestal als een kleine helper, een anemic model als "slechts DTOs", en verstijft dan.
Ze een naam geven geeft teams een gedeeld vocabulaire voor vroege waarschuwingen in code review, en elk anti-pattern wijst rechtstreeks naar het principe (SRP, compositie, inkapseling) dat het oplost.