Anti-pattern là những "giải pháp" lặp đi lặp lại trông có vẻ hợp lý nhưng làm suy thoái một thiết kế. Phổ biến nhất trong OOP là God Object, các cây kế thừa sâu, và Anemic Domain Model (mô hình miền thiếu máu).
Một class biết và làm quá nhiều — vi phạm Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Mỗi cấp couple với tất cả tổ tiên; một thay đổi gần đỉnh lan tỏa khắp nơi (base class mong manh). Khắc phục: làm phẳng bằng composition; ưu tiên các khả năng "has-a" hơn các chuỗi "is-a" sâu.
Các object chỉ là túi đựng getter/setter với toàn bộ logic sống ở nơi khác — OOP chỉ trên danh nghĩa.
// THIẾU MÁU: dữ liệu không có hành vi; quy tắc sống trong một "service" riêng
class Order { List<Item> items; double total; /* chỉ getter/setter */ }
class OrderService { double calcTotal(Order o) { ... } } // logic bị đày đi nơi khác
// GIÀU CÓ: hành vi sống cùng dữ liệu mà nó thao tác
class Order {
private List<Item> items;
double total() { return items.stream().mapToDouble(Item::price).sum(); }
}
→ Vấn đề yo-yo (nhảy lên/xuống một cây phân cấp sâu để theo dõi logic)
→ Phụ thuộc vòng (A cần B cần A)
→ Feature envy (một method chủ yếu dùng dữ liệu của class khác)
Anti-pattern là cách các ý định tốt mục ruỗng: một God Object thường khởi đầu là một helper nhỏ, một mô hình thiếu máu là "chỉ vài DTO," rồi hóa đá.
Gọi tên chúng cho các đội một vốn từ vựng cảnh báo sớm chung trong code review, và mỗi anti-pattern chỉ thẳng tới nguyên tắc (SRP, composition, encapsulation) khắc phục nó.