Anti-kuviot ovat toistuvat "ratkaisut", jotka näyttävät järkeviltä, mutta heikentävät suunnittelua. OOP:ssä yleisimmät ovat God Object, syvät perintöhierarkiat ja Anemic Domain Model.
Luokka, joka tietää ja tekee liian paljon — rikkoo Single Responsibility -periaatteen.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Jokainen taso kytkeytyy kaikkiin esi-isiin; muutos lähellä huippua leviää kaikkialle (fragile base class). Ratkaisu: tasoita composition-avulla; suosi "has-a"-ominaisuuksia syvien "is-a"-ketjujen sijaan.
Objektit, jotka ovat vain getters/setters -säkkejä ja kaikki logiikka asuu muualla — OOP vain nimeltään.
// 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-kuviot ovat kuinka hyvät aikomukset rappeutuvat: God Object alkaa yleensä pieneksi apuriksi, anemic-malli vain "DTOiksi", sitten se kovettuu.
Niiden nimeäminen antaa tiimeille jaetun varhaisen varoituksen sanastoon koodin arvioinnissa, ja jokainen anti-kuvio osoittaa suoraan periaatteeseen (SRP, composition, encapsulation), joka sen korjaa.