Anti-patterns are recurring "solutions" that look reasonable but degrade a design. The most common in OOP are the God Object, deep inheritance hierarchies, and the Anemic Domain Model.
A class that knows and does too much — violating Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Each level couples to all ancestors; a change near the top ripples everywhere (fragile base class). Fix: flatten with composition; prefer "has-a" capabilities over deep "is-a" chains.
Objects that are just bags of getters/setters with all logic living elsewhere — OOP in name only.
// 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-patterns are how good intentions rot: a God Object usually starts as a small helper, an anemic model as "just DTOs," then ossifies.
Naming them gives teams a shared early-warning vocabulary in code review, and each anti-pattern points directly at the principle (SRP, composition, encapsulation) that fixes it.