Anti-Patterns sind wiederkehrende "Lösungen", die vernünftig wirken, aber ein Design verschlechtern. Die häufigsten in OOP sind God Object, tiefe Vererbungshierarchien und Anemic Domain Model.
Eine Klasse, die zu viel weiß und tut — verletzt Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Jede Ebene koppelt sich an alle Vorfahren; eine Änderung in der Nähe der Spitze verbreitet sich überall (fragile base class). Lösung: mit Composition abflachen; "has-a"-Fähigkeiten gegenüber tiefen "is-a"-Ketten bevorzugen.
Objekte, die nur Beutel von Gettern/Settern mit der ganzen Logik anderswo sind — OOP nur dem Namen nach.
// 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 sind, wie gute Absichten verrotten: Ein God Object beginnt normalerweise als kleiner Helfer, ein anemisches Modell als "nur DTOs", dann verhärtet es sich.
Sie zu benennen gibt Teams ein gemeinsames Frühwarningsvokabular in Code-Reviews, und jedes Anti-Pattern verweist direkt auf das Prinzip (SRP, composition, encapsulation), das es repariert.