SOLID रखरखाव योग्य, लचकदार OOP सिस्टम बनाने के लिए पाँच डिजाइन सिद्धांत हैं। प्रत्येक कठोर, नाजुक कोड के एक सामान्य कारण को संबोधित करता है।
SOLID रखरखाव योग्य, लचकदार OOP सिस्टम बनाने के लिए पाँच डिजाइन सिद्धांत हैं। प्रत्येक कठोर, नाजुक कोड के एक सामान्य कारण को संबोधित करता है।
| अक्षर | सिद्धांत | एक-पंक्ति अर्थ |
|---|
| S | एकल जिम्मेदारी | एक वर्ग के परिवर्तन का केवल एक कारण होना चाहिए |
| O | खुला/बंद | विस्तार के लिए खुला, संशोधन के लिए बंद |
| L | लिस्कोव प्रतिस्थापन | सबटाइप्स को आधार प्रकार के जहाँ भी उपयोग किया जा सकता है |
| I | इंटरफेस विभाजन | कई छोटे इंटरफेस एक बड़े से बेहतर हैं |
| D | निर्भरता व्युत्क्रमण | अमूर्ततावों पर निर्भर करें, ठोस वर्गों पर नहीं |
# 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 विशेष रूप से ईमेल पर निर्भर नहीं है — इसे छुए बिना SMS या परीक्षण डबल के साथ स्वैप करें (D)। एक नए नोटिफायर प्रकार को जोड़ने के लिए OrderService में कोई बदलाव की आवश्यकता नहीं है (O)।
SOLID मार्गदर्शन है, कानून नहीं। इसे अत्यधिक लागू करना — प्रति वर्ग एक इंटरफेस, हर जगह परोक्षता — "अमूर्तता सूप" का उत्पादन करता है जो इसके द्वारा हल की गई समस्या से अनुसरण करना कठिन है।
SOLID साझा निदान भाषा प्रदान करता है: समीक्षक नाम दे सकते हैं क्यों एक वर्ग बदलना मुश्किल है ("यह SRP का उल्लंघन करता है") स्वाद से बहस करने के बजाय।
सात लागू किए जाने पर, सिद्धांत लहर प्रभाव को कम करते हैं — परिवर्तन स्थानीय रहते हैं, नई सुविधाएँ फिर से लिखने के बजाय विस्तृत होती हैं, और परीक्षण वास्तविक निर्भरताओं के लिए नकली को प्रतिस्थापित कर सकते हैं।