anti-patterns ทั่วไปของ OOP มีอะไรบ้าง?

Question

Accepted Answer

Anti-patterns คือ "โซลูชัน" ที่เกิดขึ้นซ้ำๆ ที่ดูสมเหตุสมผล แต่ทำให้การออกแบบเสื่อมลง anti-patterns ที่พบบ่อยที่สุดใน OOP ได้แก่ **God Object**, **deep inheritance hierarchies** และ **Anemic Domain Model** ## God Object คลาสที่รู้จักและทำหลายอย่างเกินไป - ละเมิด Single Responsibility ```java class AppManager { // 5,000 lines, touches everything void parseRequest() {} void queryDb() {} void renderHtml() {} void sendEmail() {} void logMetrics() {} void authUser() {} } // Fix: split into focused, cohesive classes (Router, Repo, View, Mailer...) ``` ## Deep inheritance hierarchies ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` แต่ละระดับเชื่อมต่อกับบรรพบุรุษทั้งหมด การเปลี่ยนแปลงใกล้ด้านบนจะแผ่ขยายไปทั่วทุกหนทุกแห่ง (fragile base class) **แก้ไข:** ทำให้เรียบด้วย composition เลือก "has-a" capabilities แทน deep "is-a" chains ## Anemic Domain Model วัตถุที่เป็นเพียงกระเป๋าของ getters/setters โดยมีลอจิกทั้งหมดอยู่ที่อื่น - OOP เพียงชื่อเท่านั้น ```java // ANEMIC: data with no behavior; rules live in a separate "service" class Order { List 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 items; double total() { return items.stream().mapToDouble(Item::price).sum(); } } ``` ## อื่นๆ ที่ควรนำเสนอ ```text → 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 คือวิธีที่ความตั้งใจดีเสื่อมลง: God Object มักจะเริ่มต้นจากตัวช่วยขนาดเล็ก anemic model เป็น "just DTOs" แล้วก็แข็งตัว การตั้งชื่อให้พวกเขาทำให้ทีมมีศัพท์เตือนด้านเร็วที่ใช้ร่วมกันในการ code review และแต่ละ anti-pattern ชี้ไปที่หลักการ (SRP, composition, encapsulation) ที่แก้ไขได้โดยตรง