Anti-tiparele sunt "soluții" recurente care par rezonabile, dar degradează un design. Cele mai comune în OOP sunt God Object, ierarhiile de moștenire profunde și Anemic Domain Model.
O clasă care știe și face prea mult — încălcând Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Fiecare nivel se cupleaza la toți strămoșii; o schimbare în partea de sus se răspândește peste tot (clasa de bază fragilă). Soluție: aplatizează cu compoziție; preferă capacitățile "has-a" în locul lanțurilor "is-a" profunde.
Obiecte care sunt doar pungi de getteri/setteri cu toată logica trăind în altă parte — OOP doar ca nume.
// 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-tiparele sunt cum se strica bunele intenții: un God Object de obicei pornește ca un mic helper, un model anemic ca "doar DTOs", apoi se osifică.
Le da un nume ofera echipelor un vocabular partajat de avertizare timpurie în revizuirea codului, și fiecare anti-tipar indică direct principiul (SRP, compoziție, încapsulare) care îl rezolvă.