C# में SOLID सिद्धांत: सिद्धांत और व्यवहारिक उपयोग

C# में SOLID सिद्धांतों का परिचय

.NET इकोसिस्टम में C# में डेवलपमेंट के लिए सिर्फ सिंटैक्स का ज्ञान ही नहीं, बल्कि लचीली, मेंटेन करने योग्य और टेस्ट करने योग्य सिस्टम डिज़ाइन करने की क्षमता भी ज़रूरी है। इसी उद्देश्य के लिए SOLID सिद्धांत बनाए गए — ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के पाँच मूलभूत नियम, जिन्हें रॉबर्ट मार्टिन (अंकल बॉब) ने प्रतिपादित किया।

SOLID का अर्थ है:

\n
• S — Single Responsibility Principle (एकल उत्तरदायित्व सिद्धांत)
\n
• O — Open/Closed Principle (खुला/बंद सिद्धांत)
\n
• L — Liskov Substitution Principle (लिस्कोव प्रतिस्थापन सिद्धांत)
\n
• I — Interface Segregation Principle (इंटरफ़ेस पृथक्करण सिद्धांत)
\n
• D — Dependency Inversion Principle (निर्भरता उलटाव सिद्धांत)
\n

इस लेख में हम प्रत्येक सिद्धांत को C# उदाहरणों के साथ व्यवहारिक रूप से समझेंगे, दिखाएंगे कि उनका उल्लंघन कैसे समस्याएँ पैदा करता है, और सही अनुप्रयोग कोड को कैसे साफ़ बनाता है।

1. एकल उत्तरदायित्व सिद्धांत (SRP)

सार: एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, प्रत्येक क्लास एक स्पष्ट रूप से परिभाषित कार्य के लिए जिम्मेदार होती है।

C# में SRP का उल्लंघन

एक सामान्य उदाहरण देखें — OrderService क्लास, जो बहुत अधिक काम करती है:

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. डेटाबेस में सेव करना\n        SaveToDatabase(order);\n        \n        // 2. ईमेल भेजना\n        SendEmail(order.CustomerEmail, "ऑर्डर कन्फर्म");\n        \n        // 3. लॉगिंग\n        File.WriteAllText("log.txt", $"ऑर्डर {order.Id} प्रोसेस हुआ");\n    }\n    \n    private void SaveToDatabase(Order order) { /* ... */ }\n    private void SendEmail(string email, string message) { /* ... */ }\n}

समस्या: ईमेल भेजने या लॉगिंग के तरीके में बदलाव से OrderService क्लास में बदलाव होगा। यह SRP का उल्लंघन है।

SRP की सही व्यवहारिकता

जिम्मेदारी को अलग-अलग सर्विसेज़ में बाँटें:

public class OrderProcessor\n{\n    private readonly IOrderRepository _repository;\n    private readonly INotificationService _notificationService;\n    private readonly ILogger _logger;\n    \n    public OrderProcessor(\n        IOrderRepository repository,\n        INotificationService notificationService,\n        ILogger logger)\n    {\n        _repository = repository;\n        _notificationService = notificationService;\n        _logger = logger;\n    }\n    \n    public void ProcessOrder(Order order)\n    {\n        _repository.Save(order);\n        _notificationService.SendConfirmation(order.CustomerEmail);\n        _logger.Log($"ऑर्डर {order.Id} प्रोसेस हुआ");\n    }\n}\n\npublic interface IOrderRepository { void Save(Order order); }\npublic interface INotificationService { void SendConfirmation(string email); }\npublic interface ILogger { void Log(string message); }

अब प्रत्येक क्लास सिर्फ अपने काम के लिए जिम्मेदार है। लॉगिंग लॉजिक में बदलाव से ऑर्डर प्रोसेसिंग प्रभावित नहीं होती।

2. खुला/बंद सिद्धांत (OCP)

सार: क्लासेज़ विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद। यानी आपको मौजूदा कोड को बदले बिना नया व्यवहार जोड़ने में सक्षम होना चाहिए।

C# में OCP का उल्लंघन

एक क्लासिक उदाहरण — शर्तों वाला कैलकुलेटर:

public class AreaCalculator\n{\n    public double CalculateArea(object shape)\n    {\n        if (shape is Rectangle rect)\n            return rect.Width * rect.Height;\n        else if (shape is Circle circle)\n            return Math.PI * circle.Radius * circle.Radius;\n        // नई आकृति जोड़ने पर इस मेथड में बदलाव करना होगा!\n        throw new NotSupportedException();\n    }\n}