सॉफ्टवेयर विकास की दुनिया में, SOLID सिद्धांत हमें बताते हैं कि कार्यों और डेटा को कैसे व्यवस्थित किया जाए ताकि हमारे कोड:

• परिवर्तनों को सहन करें
• समझना आसान हो
• उन घटकों का आधार बनें जिनका उपयोग कई सॉफ्टवेयर प्रणालियों में किया जा सकता है

SOLID शब्द नीचे वर्णित पांच डिज़ाइन अभिधारणाओं का संक्षिप्त रूप है:

(एस) एकल उत्तरदायित्व सिद्धांत: "एक मॉड्यूल में बदलाव का एक और केवल एक ही कारण होना चाहिए"
(O) खुला/बंद सिद्धांत: "एक सॉफ्टवेयर आर्टिफैक्ट विस्तार के लिए खुला होना चाहिए लेकिन संशोधन के लिए बंद होना चाहिए"
(एल) लिस्कोव प्रतिस्थापन सिद्धांत: "एक व्युत्पन्न वर्ग को उसके आधार वर्ग द्वारा प्रतिस्थापित किया जाना चाहिए"
(I) इंटरफ़ेस पृथक्करण सिद्धांत: "एक वर्ग को उन इंटरफेस और विधियों को लागू करने के लिए बाध्य नहीं किया जाना चाहिए जिनका वह उपयोग नहीं करेगा"
(डी) निर्भरता व्युत्क्रम सिद्धांत: "अमूर्त पर निर्भर करें न कि कार्यान्वयन पर"

ठोस और GoLang

SOLID को ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए डिज़ाइन किया गया है, और यह ज्ञात है कि GoLang ऐसी भाषा नहीं है जो इस प्रतिमान को अपनाती है। हालाँकि, हम OOP कार्यप्रणाली को पूरा करने के लिए इसके द्वारा उपलब्ध कराए गए संसाधनों का उपयोग कर सकते हैं। उदाहरण के लिए, गो के पास वंशानुक्रम समर्थन नहीं है, लेकिन विचार को इसके रचना समर्थन से मुआवजा दिया जा सकता है। इसी प्रकार, इंटरफ़ेस का उपयोग करके एक प्रकार का बहुरूपता बनाया जा सकता है।

इस लेख में, 5 की श्रृंखला में पहला, मैं पहले सिद्धांत को उन उदाहरणों के साथ विस्तार से बताने का इरादा रखता हूं जो उन स्थितियों के करीब हैं जिनका हम दैनिक आधार पर सामना करते हैं।

एकल उत्तरदायित्व सिद्धांत (एसआरपी)

हम पहले से ही जानते हैं कि इस शब्द का क्या अर्थ है, अब यह सीखने का समय है कि इसे GoLang में कैसे लागू किया जाए।
इस भाषा में, हम इस सिद्धांत को इस प्रकार परिभाषित कर सकते हैं "एक फ़ंक्शन या प्रकार में एक और केवल एक कार्य और एक और केवल एक जिम्मेदारी होनी चाहिए", आइए निम्नलिखित कोड देखें:

ऊपर, हमारे पास एक संरचना है जिसे हम userService कहते हैं। इसके दो गुण हैं: db जो एक रिलेशनल डेटाबेस के साथ संचार करने के लिए ज़िम्मेदार है, और amqpChannel, जो RabbitMQ मैसेजिंग सेवा के साथ संचार सक्षम बनाता है।

UserService Create नामक एक विधि लागू करता है। इस पद्धति के अंतर्गत हम प्राप्त उपयोगकर्ता जानकारी को डेटाबेस में संग्रहीत करते हैं और फिर डेटा को RabbitMQ पर प्रकाशित करते हैं।
यह देखा जा सकता है कि उपयोगकर्ता सेवा में क्रिएट विधि की ज़िम्मेदारी सिर्फ एक नहीं है, बल्कि दो है: डेटाबेस में जानकारी संग्रहीत करना और RabbitMQ कतार में एक संदेश प्रकाशित करना।

इससे कई समस्याएं पैदा हो सकती हैं, जैसे:

• बनाए रखना मुश्किल: यदि आवश्यकताओं में से एक बदलता है, जैसे कि उपयोगकर्ता डेटा को क्रमबद्ध करने का तरीका, तो आपको क्रिएट विधि के तर्क को संशोधित करना होगा, भले ही इसका आपकी मुख्य जिम्मेदारी से कोई लेना-देना न हो, जो कि है डेटाबेस में डेटा सहेजें।
• परीक्षण कठिनाई: चूंकि क्रिएट विधि में दो अलग-अलग जिम्मेदारियां हैं, आपको उनमें से प्रत्येक के लिए परीक्षण बनाना होगा, जो कठिन और श्रमसाध्य हो सकता है।
• अनावश्यक युग्मन: उपयोगकर्ता डेटा को RabbitMQ कतार में प्रकाशित करने का तर्क इस डेटा को डेटाबेस में सहेजने के तर्क से पूरी तरह से स्वतंत्र है। इन दोनों जिम्मेदारियों को एक ही विधि में मिलाने से अनावश्यक युग्मन बनता है।

निम्नलिखित कोड में, हम एसआरपी का सम्मान करने के लिए संरचना को संशोधित करते हैं। इसकी जांच - पड़ताल करें:

ध्यान दें कि हमने जिम्मेदारियों को तीन अलग-अलग हिस्सों में विभाजित किया है: उपयोगकर्ता को डेटाबेस में बनाए रखने के लिए रिपॉजिटरी UserRepository, RabbitMQ को एक संदेश भेजने के लिए प्रकाशक UserPublisher, और सेवा UserService जो इन दो परिचालनों को व्यवस्थित करती है।

इस तरह, प्रत्येक घटक एक विशिष्ट और स्वतंत्र कार्य के लिए जिम्मेदार है, जो कोड के रखरखाव और विकास की सुविधा प्रदान करता है, इसके अलावा इनमें से प्रत्येक भाग को दूसरों को प्रभावित किए बिना बदलने या सुधारने की अनुमति देता है। उदाहरण के लिए, यदि उपयोग किए गए डेटाबेस को बदलना आवश्यक है, तो बस रिपॉजिटरी को बदलें। यदि संचार का स्वरूप बदलना आवश्यक है, तो बस प्रकाशक को बदल दें।

यह उल्लेखनीय है कि दो अलग-अलग कार्यों को करने और उनके निष्पादन को सौंपने के बीच एक सूक्ष्म अंतर है। userService.Create के मूल उदाहरण में, एकल जिम्मेदारी के सिद्धांत का उल्लंघन करते हुए, एक ही स्थान पर दो ऑपरेशन किए गए थे। रीफैक्टरिंग के बाद, हमने विभिन्न संरचनाओं को निष्पादन सौंप दिया और क्रिएट विधि केवल इस प्रवाह के समन्वय के लिए जिम्मेदार थी।

इस उदाहरण में एसआरपी लागू करने के लिए, हमने कुछ अन्य ठोस सिद्धांतों को भी लागू किया:

• इंटरफ़ेस पृथक्करण सिद्धांत (आईएसपी): प्रत्येक इंटरफ़ेस एक ही जिम्मेदारी का प्रतिनिधित्व करता है। UserRepository और UserPublisher दोनों ऐसे इंटरफ़ेस हैं जिनमें केवल एक ही विधि है, प्रत्येक एक ही जिम्मेदारी का प्रतिनिधित्व करता है।
• निर्भरता व्युत्क्रम सिद्धांत (DIP): उपयोगकर्ता सेवा संरचना अमूर्त (इंटरफ़ेस) पर निर्भर करती है न कि ठोस कार्यान्वयन पर, यानी, यह UserRepository और UserPublisher के विशिष्ट कार्यान्वयन को नहीं जानता है, केवल इंटरफ़ेस जो वे कार्यान्वित करते हैं।
• खुला/बंद सिद्धांत (ओसीपी): कोड विस्तार के लिए खुला है, क्योंकि नए रिपॉजिटरी या प्रकाशकों को उपयोगकर्ता सेवा को संशोधित किए बिना आसानी से जोड़ा जा सकता है।

इस श्रृंखला के अगले लेखों में मैं विशिष्ट उदाहरणों के साथ उनमें से प्रत्येक का अधिक विस्तृत विवरण प्रदान करूंगा।

बाद में मिलते हैं, दोस्तों!

संदर्भ:
ठोस: ऑब्जेक्ट ओरिएंटेड डिज़ाइन के पहले 5 सिद्धांत
स्वच्छ कोडर ब्लॉग - एकल उत्तरदायित्व सिद्धांत