SOLID रक्षणयोग्य, लचकदार OOP प्रणाली निर्माण गर्नका लागि पाँच डिजाइन सिद्धान्त हुन्। प्रत्येकले कठोर, नाजुक कोडको साधारण कारण सम्बोधन गर्छ।
SOLID रक्षणयोग्य, लचकदार OOP प्रणाली निर्माण गर्नका लागि पाँच डिजाइन सिद्धान्त हुन्। प्रत्येकले कठोर, नाजुक कोडको साधारण कारण सम्बोधन गर्छ।
| अक्षर | सिद्धान्त | एक-लाइन अर्थ |
|---|
| S | Single Responsibility | एक क्लासको परिवर्तनको एक कारण हुनु चाहिए |
| O | Open/Closed | विस्तारका लागि खुला, संशोधनका लागि बन्द |
| L | Liskov Substitution | Subtypes आधार प्रकार भएको जहाँ प्रयोग गर्न सकिनु पर्छ |
| I | Interface Segregation | धेरै साना interfaces एक मोटो भन्दा राम्रो |
| D | Dependency Inversion | abstractions मा निर्भर गर्नुहोस्, concrete classes मा होइन |
# 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 साझा निदान भाषा दिन्छ: समीक्षकहरूले नाम गर्न सक्छन् किन क्लास परिवर्तन गर्न गाह्रो छ ("यो SRP उल्लंघन गर्छ") स्वाद द्वारा बहस गर्नुको सट्टा।
न्याय सहित लागु गरी, सिद्धान्तहरूले ripple प्रभाव कम गर्छन् — परिवर्तनहरू स्थानीय रहन्छन्, नयाँ सुविधाहरू पुनर्लेखन गर्नुको सट्टा विस्तार गर्छन्, र परीक्षणहरूले वास्तविक निर्भरताहरुको लागि नकलहरू प्रतिस्थापन गर्न सक्छन्।