آپ کسی ڈومین کو اچھی طریقے سے ڈیزائن کی گئی کلاسز میں کیسے ماڈل کرتے ہیں؟

Question

Accepted Answer

اچھی کلاس ماڈلنگ کا مطلب ایسی کلاسز ہیں جو حقیقی ڈومین کے تصورات سے منطبق ہوں، ہر ایک کے ساتھ **ایک واضح ذمہ داری**، **is-a/has-a** کے ایمانداری سے متعلق تعلقات، اور **abstractions** پر سرحدوں پر منحصر۔ کوئی فارمولہ نہیں ہے، لیکن ایک دہرایا جانے والا عمل ہے۔ ## عملی عمل ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## رویہ ڈیٹا کی پیروی کرتا ہے ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## Heuristics جو درختوں کو صحت مند رکھتے ہیں | Heuristic | کیوں | |---|---| | Composition کو ترجیح دیں؛ inheritance کو صرف حقیقی is-a کے لیے استعمال کریں | Fragile base class / LSP کے پھندوں سے بچاتا ہے | | درختوں کو اتلی رکھیں (2–3 سطریں) | گہری درختیں سب کچھ جوڑتی ہیں | | SRP کے مطابق ہر کلاس میں تبدیل ہونے کی ایک وجہ | تبدیلی کو مقام بندی کرتا ہے | | seams پر interfaces کے لیے پروگرام کریں | Testability، swappability | | value objects کو immutable بنائیں | بگ کی ایک کلاس کو ختم کرتا ہے | ## خطرہ پورے عالم کو شروع سے ماڈل نہ کریں۔ concrete کلاسز کے ساتھ چھوٹے سے شروع کریں؛ abstractions کو صرف تب نکالیں جب حقیقی تنوع ظاہر ہو (تین کا قاعدہ)۔ Speculative درختیں برے طریقے سے عمر کو تقسیم کرتی ہیں۔ ## اس کا اہم ہونا ایک ماڈل جو ڈومین کی عکاسی کرتا ہے کوڈ کو خود تشریح کنندہ بناتا ہے — ایک نیا انجنیئر `order.refund()` پڑھتا ہے اور کاروبار کو سمجھتا ہے، نہ کہ صرف syntax کو۔ فائدہ بڑھتا ہے: ہم آہنگ، ڈھیلے طریقے سے جڑی کلاسز تبدیلی کو مقام بندی کرتی ہیں، اس لیے خصوصیات اور bug کی اصلاحات کچھ فائلوں کو چھوتی ہیں بجائے نظام کے ذریعے سے لہریں پڑنے کے۔

Heuristic	کیوں
Composition کو ترجیح دیں؛ inheritance کو صرف حقیقی is-a کے لیے استعمال کریں	Fragile base class / LSP کے پھندوں سے بچاتا ہے
درختوں کو اتلی رکھیں (2–3 سطریں)	گہری درختیں سب کچھ جوڑتی ہیں
SRP کے مطابق ہر کلاس میں تبدیل ہونے کی ایک وجہ	تبدیلی کو مقام بندی کرتا ہے
seams پر interfaces کے لیے پروگرام کریں	Testability، swappability
value objects کو immutable بنائیں	بگ کی ایک کلاس کو ختم کرتا ہے