অ্যান্টি-প্যাটার্নগুলি পুনরাবৃত্ত "সমাধান" যা যুক্তিসঙ্গত দেখায় কিন্তু ডিজাইনকে হ্রাস করে। OOP এ সবচেয়ে সাধারণগুলি হল God Object, গভীর ইনহেরিট্যান্স হায়ারার্কি এবং Anemic Domain Model।
একটি ক্লাস যা খুব বেশি কিছু জানে এবং করে — Single Responsibility লঙ্ঘন করে।
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
প্রতিটি স্তর সমস্ত পূর্বসূরীদের সাথে সংযুক্ত; শীর্ষের কাছাকাছি একটি পরিবর্তন সর্বত্র ছড়িয়ে পড়ে (fragile base class)। সমাধান: composition দিয়ে সমতল করুন; গভীর "is-a" চেইনের উপর "has-a" ক্ষমতা পছন্দ করুন।
কেবলমাত্র getters/setters এর ব্যাগ সহ অবজেক্ট যেখানে সমস্ত লজিক অন্য জায়গায় থাকে — শুধুমাত্র নামে 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 মডেল "শুধু DTOs" হিসাবে, তারপর হার্ডেন হয়ে যায়।
তাদের নাম দেওয়া টিমগুলিকে কোড পর্যালোচনায় একটি ভাগ করা প্রাথমিক-সতর্কতা শব্দভাণ্ডার দেয়, এবং প্রতিটি অ্যান্টি-প্যাটার্ন সরাসরি সেই নীতিটি নির্দেশ করে (SRP, composition, encapsulation) যা এটি ঠিক করে।