反模式是不断重复出现的"解决方案"，看起来合理但会降低设计质量。OOP中最常见的是God Object、深层继承层级和Anemic Domain Model。
God Object
一个了解和做太多事情的类——违反了单一职责原则。
java
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
每个层级都与所有祖先耦合；顶部附近的更改会波及各处（脆弱基类问题）。解决方案： 使用组合来扁平化；优先使用"has-a"能力而不是深层"is-a"链。
对象只是包含getter/setter的数据容器，所有逻辑都存在于其他地方——只是名义上的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通常从一个小的辅助开始，Anemic Model作为"只是DTO"，然后逐渐固化。
给它们命名为团队在代码审查中提供了共享的早期预警词汇，每个反模式都直接指向修复它的原则（SRP、组合、封装）。