Anty-wzorce to powtarzające się "rozwiązania", które wyglądają rozsądnie, ale degradują projektowanie. Najczęściej spotykane w OOP to God Object, głębokie hierarchie dziedziczenia i Anemic Domain Model.
Klasa, która wie i robi zbyt wiele — narusza Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Każdy poziom wiąże się ze wszystkimi przodkami; zmiana na górze rozprzestrzenia się wszędzie (fragile base class). Rozwiązanie: spłaszczaj za pomocą kompozycji; preferuj możliwości "has-a" zamiast głębokich łańcuchów "is-a".
Obiekty, które są tylko workkami getterów/setterów ze wszystką logiką żyjącą gdzie indziej — OOP tylko z nazwy.
// 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)
Anty-wzorce to jak dobre zamiary się psują: God Object zwykle zaczyna się jako mały pomocnik, anemic model jako "tylko DTOs", potem powiększa się.
Nadanie im nazwy daje zespołom wspólny wokabularz wczesnego ostrzegania w przeglądzie kodu, a każdy anty-wzorzec wskazuje bezpośrednio na zasadę (SRP, composycja, enkapsulacja), która go naprawia.