Anti-mønstre er gjentakende "løsninger" som ser rimelige ut, men forverrer en design. De vanligste innen OOP er God Object, dype arveringshierarkier og Anemic Domain Model.
En klasse som vet og gjør for mye — bryter Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Hvert nivå kpler til alle forgjengere; en endring høyt oppe brer seg overalt (fragil basisklasse). Løsning: flat ut med komposisjon; foretrekk "has-a" evner over dype "is-a" kjeder.
Objekter som bare er poser med getters/setters med all logikk et annet sted — OOP bare i navn.
// 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-mønstre er hvordan gode intensjoner råtner: en God Object starter vanligvis som en liten hjelpefunksjon, en anemic model som "bare DTOer", og så blir stiv.
Å gi dem navn gir team et delt tidlig-varslingsvokabular i kodegjennomgang, og hvert anti-mønster peker direkte på prinsippet (SRP, komposisjon, innkapsling) som fikser det.