HI
RU
EN
ES
ZH
FR
DE
PT
AR
परिचय: जब SOLID सिद्धांत सिद्धांत से व्यवहार में बदल जाता है
\nअधिकांश डेवलपर्स SOLID संक्षिप्त नाम को "क्लास को एक चीज़ के लिए जिम्मेदार होना चाहिए" के स्तर पर जानते हैं। हालांकि, Dependency Injection, माइक्रोसर्विसेज और एसिंक्रोनस पैटर्न वाले C# (.NET) वास्तविक प्रोजेक्ट्स में, सिद्धांतों का भोलेपन से पालन करना विपरीत प्रभाव डालता है - अत्यधिक जटिलता, इंटरफेस का फूलना और एनकैप्सुलेशन का उल्लंघन।
\nइस लेख में, हम SOLID को हठधर्मिता के एक सेट के रूप में नहीं, बल्कि आर्किटेक्चरल निर्णय लेने के लिए एक उपकरण के रूप में देखेंगे। आप सीखेंगे कि उन्नत परिदृश्यों में सिद्धांतों को सही तरीके से कैसे लागू किया जाए: IoC-कंटेनरों के साथ काम करना, वंशानुक्रम के बजाय संयोजन, इंटरफेस के माध्यम से त्रुटि प्रबंधन और सागा परीक्षण।
\n\n1. Single Responsibility: DDD में जिम्मेदारी की सीमाएँ
\nएकल जिम्मेदारी सिद्धांत (SRP) को अक्सर "एक क्लास - एक फंक्शन" के साथ भ्रमित किया जाता है। वास्तव में, यह परिवर्तन के कारण (reason to change) के बारे में है। C# और Domain-Driven Design के संदर्भ में, इसका मतलब है कि एक क्लास को केवल एक कारण से बदलना चाहिए, जो एक अभिनेता या व्यावसायिक नियम से संबंधित हो।
\n\nउन्नत एंटीपैटर्न: "दिव्य Entity"
\n.NET में SRP उल्लंघन का एक विशिष्ट उदाहरण देखें - क्लास OrderEntity, जो एक साथ ऑर्डर की स्थिति का प्रबंधन करता है, करों की गणना करता है, ईमेल भेजता है और Entity Framework के माध्यम से डेटाबेस में डेटा सहेजता है।
// ❌ SRP का उल्लंघन\npublic class OrderEntity\n{\n public int Id { get; set; }\n public decimal Total { get; set; }\n public string Email { get; set; }\n\n public void CalculateTax() { /* कर तर्क */ }\n public void SendConfirmation() { /* ईमेल भेजना */ }\n public void SaveToDatabase() { /* EF Core SaveChanges */ }\n}\nसमस्या: करों पर व्यावसायिक नियम में बदलाव (उदाहरण के लिए, एक नया कानून) उस क्लास में बदलाव लाएगा जो अधिसूचना भेजने के लिए भी जिम्मेदार है। इससे प्रतिगमन का जोखिम बढ़ जाता है।
\n\nसमाधान: DI के माध्यम से सेवाओं का पृथक्करण
\n// ✅ सेवाओं के माध्यम से SRP\npublic class Order\n{\n public int Id { get; set; }\n public decimal Total { get; set; }\n // केवल स्थिति, कोई तर्क नहीं\n}\n\npublic class TaxCalculator : ITaxCalculator\n{\n public decimal Calculate(Order order) { /* ... */ }\n}\n\npublic class EmailService : INotificationService\n{\n public Task SendConfirmation(Order order) { /* ... */ }\n}\n\npublic class OrderRepository : IRepository<Order>\n{\n public Task SaveAsync(Order order) { /* EF Core */ }\n}\nअब प्रत्येक क्लास के पास बदलाव का बिल्कुल एक कारण है। DI कंटेनर (Microsoft.Extensions.DependencyInjection) उन्हें कंस्ट्रक्टर के माध्यम से जोड़ता है।
\n\n2. Open/Closed: रणनीति और डेकोरेटर के माध्यम से विस्तार
\nखुले/बंद सिद्धांत (OCP) कहता है: क्लास विस्तार के लिए खुला होना चाहिए, लेकिन संशोधन के लिए बंद होना चाहिए। .NET में, यह न केवल वंशानुक्रम के माध्यम से, बल्कि Strategy और Decorator पैटर्न के साथ संयोजन के माध्यम से भी प्राप्त किया जाता है।
\n\nउन्नत मामला: नियमों के बढ़ने के साथ सत्यापन
\nकल्पना करें कि आपके पास ऑर्डर सत्यापन प्रणाली है। प्रारंभिक संस्करण केवल राशि और पते की जाँच करता था। एक महीने बाद, "सीमा से अधिक राशि के उत्पादों का ऑर्डर नहीं किया जा सकता" नियम जोड़ा गया। OrderValidator क्लास को संशोधित करने के बजाय, संयोजन का उपयोग करें।
// ❌ OCP का उल्लंघन - मौजूदा क्लास का संशोधन\npublic class OrderValidator\n{\n public bool Validate(Order order)\n {\n if (order.Total < 0) return false;\n if (string.IsNullOrEmpty(order.Address)) return false;\n // नया नियम - क्लास को संशोधित कर रहे हैं\n if (order.Total > 10000) return false;\n return true;\n }\n}\n// ✅ सत्यापनकर्ताओं के संयोजन के माध्यम से OCP\npublic interface IValidator<T>\n{\n bool Validate(T entity);\n}\n\npublic class TotalValidator : IValidator<Order>\n{\n public bool Validate(Order order) => order.Total > 0;\n}\n\npu 
