SOLID قابل دیکھ بھال، لچکدار OOP سسٹم بنانے کے لیے پانچ ڈیزائن اصول ہیں۔ ہر ایک سخت، نازک کوڈ کی ایک عام وجہ سے نمٹتا ہے۔
SOLID قابل دیکھ بھال، لچکدار OOP سسٹم بنانے کے لیے پانچ ڈیزائن اصول ہیں۔ ہر ایک سخت، نازک کوڈ کی ایک عام وجہ سے نمٹتا ہے۔
| حرف | اصول | ایک لائن کا مطلب |
|---|
| S | Single Responsibility | ایک کلاس کی تبدیلی کی صرف ایک وجہ ہونی چاہیے |
| O | Open/Closed | توسیع کے لیے کھلی، ترمیم کے لیے بند |
| L | Liskov Substitution | Subtypes بیس ٹائپ کی جگہ استعمال کے قابل ہونی چاہیں |
| I | Interface Segregation | بہت سے چھوٹے interfaces ایک موٹے سے بہتر ہیں |
| D | Dependency Inversion | concrete classes کی بجائے abstractions پر منحصر ہوں |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService براہ راست email پر منحصر نہیں ہے — اسے بغیر تبدیل کیے SMS یا ایک test double سے بدل سکتے ہیں (D)۔ ایک نیا notifier ٹائپ شامل کرنے کے لیے OrderService میں کوئی تبدیلی کی ضرورت نہیں ہے (O)۔
SOLID رہنمائی ہے، قانون نہیں۔ اس کو زیادہ لاگو کرنا — ہر کلاس کے لیے ایک interface، ہر جگہ بالواسطہ — "abstraction soup" پیدا کرتا ہے جو اس مسئلے سے سمجھنا زیادہ مشکل ہے۔
SOLID ایک مشترک تشخیصی زبان فراہم کرتا ہے: reviewers یہ نام دے سکتے ہیں کہ کیوں ایک کلاس تبدیل کرنا مشکل ہے ("یہ SRP کی خلاف ورزی کرتا ہے") ذوق کے ذریعے بحث کرنے کی بجائے۔
حکمت کے ساتھ اطلاق کرتے ہوئے، یہ اصول ripple effects کو کم کرتے ہیں — تبدیلیاں مقامی رہتی ہیں، نئی خصوصیات دوبارہ لکھنے کی بجائے توسیع کرتی ہیں، اور tests حقیقی dependencies کو نقلی سے بدل سکتے ہیں۔