Анти-паттерны — это повторяющиеся "решения", которые выглядят разумно, но ухудшают проектирование. Наиболее распространённые в OOP — это God Object, глубокие иерархии наследования и Anemic Domain Model.
Класс, который знает и делает слишком много — нарушает Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Каждый уровень связан со всеми предками; изменение вверху распространяется везде (хрупкий базовый класс). Решение: уплощайте через композицию; предпочитайте возможности "has-a" глубоким цепочкам "is-a".
Объекты, которые просто сумки геттеров/сеттеров со всей логикой, живущей в другом месте — OOP только по названию.
// 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)
Анти-паттерны — это как хорошие намерения приводят к гниению: God Object обычно начинается как маленький помощник, анемичная модель как "просто DTOs", затем окостеневает.
Называние их даёт командам общий словарь ранних предупреждений при рецензировании кода, и каждый анти-паттерн прямо указывает на принцип (SRP, композиция, инкапсуляция), который его исправляет.