Les anti-patterns sont des « solutions » récurrentes qui semblent raisonnables mais dégradent une conception. Les plus courants en OOP sont le God Object, les hiérarchies d'héritage profondes, et le Anemic Domain Model.
Une classe qui connaît et fait trop — violant Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Chaque niveau s'accouple à tous les ancêtres ; une modification près du sommet se propage partout (fragile base class). Fix : aplatir avec la composition ; préférer les capacités « has-a » aux chaînes « is-a » profondes.
Des objets qui ne sont que des sacs de getters/setters avec toute la logique résidant ailleurs — OOP de nom uniquement.
// 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)
Les anti-patterns sont comment les bonnes intentions se dégradent : un God Object commence habituellement comme un petit helper, un modèle anémique comme « juste des DTOs », puis s'ossifie.
Les nommer donne aux équipes un vocabulaire d'alerte précoce partagé lors de la revue de code, et chaque anti-pattern pointe directement vers le principe (SRP, composition, encapsulation) qui le corrige.