OOP میں عام anti-patterns کیا ہیں؟

Question

Accepted Answer

Anti-patterns بار بار آنے والے "حل" ہیں جو معقول لگتے ہیں لیکن ڈیزائن کو خراب کرتے ہیں۔ OOP میں سب سے عام **God Object**، **گہری وراثت کے درختوں**، اور **Anemic Domain Model** ہیں۔ ## God Object ایک class جو بہت زیادہ جانتی ہے اور بہت کچھ کرتی ہے — 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...) ``` ## گہری وراثت کے درخت ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` ہر سطح تمام اجداد سے منسلک ہے؛ اوپر کے قریب ایک تبدیلی ہر جگہ پھیل جاتی ہے (نازک base class)۔ **حل:** composition کے ساتھ سطح کو صاف کریں؛ گہری "is-a" سلسلے کی بجائے "has-a" صلاحیتوں کو ترجیح دیں۔ ## 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 عام طور پر ایک چھوٹے helper سے شروع ہوتا ہے، ایک anemic model "صرف DTOs" سے، پھر سخت ہو جاتا ہے۔ انہیں نام دینا ٹیموں کو code review میں ابتدائی انتباہ کی مشترکہ لغت فراہم کرتا ہے، اور ہر anti-pattern براہ راست اس اصول کی طرف اشارہ کرتا ہے (SRP، composition، encapsulation) جو اسے ٹھیک کرتا ہے۔