SOLID सिद्धांतों को समझना

SOLID सिद्धांतों पांच ऑब्जेक्ट-उन्मुख डिजाइन दिशानिर्देश हैं जो डेवलपर्स को सिस्टम बनाने में मदद करते हैं जो 2000 के दशक के आरंभ में रॉबर्ट सी मार्टिन द्वारा पेश किए गए थे और तब से आधुनिक सॉफ्टवेयर आर्किटेक्चर का एक आधारशिला बन गया है। प्रत्येक सिद्धांत सॉफ्टवेयर डिजाइन के एक विशिष्ट पहलू को संबोधित करता है:

  • एकल उत्तरदायित्व सिद्धांत (SRP): एक वर्ग में केवल एक ही कारण का परिवर्तन होना चाहिए, जिसका अर्थ है कि यह एक ही कार्यक्षमता के लिए जिम्मेदार होना चाहिए।
  • Open/Closed Principle (OCP): क्लासेस को एक्सटेंशन के लिए खुला होना चाहिए लेकिन संशोधन के लिए बंद होना चाहिए - आप मौजूदा कोड को बदलने के बिना नए व्यवहार जोड़ सकते हैं।
  • ]Liskov प्रतिस्थापन सिद्धांत (LSP): सबटाइप सिस्टम को तोड़ने के बिना उनके आधार प्रकारों के लिए प्रतिस्थापन होना चाहिए।
  • ]इंटरफेस अलगाव सिद्धांत (ISP): क्लाइंट को उन इंटरफेसों पर निर्भर करने के लिए मजबूर नहीं होना चाहिए जिनका वे उपयोग नहीं करते हैं; एक बड़े, सामान्य उद्देश्य इंटरफ़ेस की तुलना में कई छोटे, विशिष्ट इंटरफेस होने के लिए बेहतर।
  • Dependency Inversion सिद्धांत (DIP):] उच्च स्तरीय मॉड्यूल निम्न स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए; दोनों अमूर्तता पर निर्भर होना चाहिए। Abstractions विवरण पर निर्भर नहीं होना चाहिए - विवरण अमूर्तता पर निर्भर होना चाहिए।

सॉफ्टवेयर आर्किटेक्चर विजुअलाइजेशन में UML की भूमिका

एकीकृत मॉडलिंग भाषा (UML) दृश्य प्रणाली डिजाइन के लिए एक मानकीकृत नोटेशन प्रदान करता है। आरेख डेवलपर्स, आर्किटेक्ट्स और हितधारकों के बीच एक साझा भाषा के रूप में कार्य करते हैं, जिससे जटिल संरचनाओं को संवाद करना आसान हो जाता है। जब SOLID-compliant आर्किटेक्चर पर लागू होता है, तो UML आरेख बताते हैं कि कितनी अच्छी तरह से डिजाइन सिद्धांतों और हाइलाइट क्षेत्रों का पालन करता है जिसे पुनर्निर्माण की आवश्यकता हो सकती है।

UML में 14 आरेख प्रकार शामिल हैं, लेकिन SOLID विज़ुअलाइज़ेशन के लिए सबसे प्रासंगिक वर्ग आरेख, घटक आरेख, अनुक्रम आरेख और पैकेज आरेख हैं। प्रत्येक आरेख प्रकार सिद्धांतों के विभिन्न पहलुओं पर जोर दे सकता है - उदाहरण के लिए, वर्ग आरेख कक्षा की जिम्मेदारियों और इंटरफेस दिखाते हैं, जबकि घटक आरेख निर्भरता निर्देशों और व्यापकता बिंदुओं को उजागर करते हैं।

प्रत्येक सोलिड सिद्धांत के लिए UML आरेखों का मानचित्रण

एकल उत्तरदायित्व सिद्धांत और कक्षा आरेख

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

उदाहरण के लिए, एक वर्ग जिसका नाम `InvoiceManager` है जो दोनों चालान गणना और ईमेल भेजने वाले वाइलेट्स SRP को संभालती है। वर्ग आरेख में उसी बॉक्स के अंदर `calculateTotal()` और `sendEmail()` जैसे तरीके दिखाए जाएंगे, जिससे वर्ग को 'InvoiceCalculator` और `EmailService` में विभाजित करने की आवश्यकता का संकेत मिलता है। जिम्मेदारी सीमाओं को चिह्नित करना नेत्रहीन रूप से टीमों को जल्दी उल्लंघन करने में मदद करता है।

ओपन / क्लोज्ड प्रिंसिपल और घटक आरेख

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

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

Liskov प्रतिस्थापन सिद्धांत और विरासत पदानुक्रम

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

एक क्लासिक LSP उल्लंघन एक `Square` वर्ग है जो `Rectangle` से विरासत में आता है। आरेख में, यदि `Square` में `setWidth()` को 'height` सेट करने के लिए बदलता है, तो यह `Rectangle` अनुबंध को तोड़ता है। आरेख को यह दिखाना चाहिए कि `Square` वास्तव में प्रतिस्थापन नहीं है। इसे ठीक करने के लिए, आप अलग-अलग `Rectangle` और `Square` कार्यान्वयन के साथ एक आम `Shape` इंटरफ़ेस का उपयोग कर सकते हैं - फिर वर्ग आरेख उनके बीच कोई सीधा विरासत नहीं दिखाएगा।

इंटरफ़ेस अलगाव सिद्धांत और इंटरफ़ेस आरेख

UML इंटरफ़ेस को स्पष्ट रूप से इंटरफ़ेस बॉक्स ("<>` स्टीरियोटाइप के साथ) का उपयोग कर सकता है। ISP को लागू करने के लिए, आप एक बड़े इंटरफ़ेस के बजाय कई छोटे इंटरफेस बना सकते हैं। आरेख बताता है कि कौन से वर्ग किस इंटरफेस पर निर्भर हैं; यदि किसी वर्ग के पास इंटरफेस में अप्रयुक्त विधियां हैं, तो इसका उल्लंघन है।

उदाहरण के लिए, `MultiFunctionPrinter` इंटरफ़ेस के बजाय `print()`, `scan()`, `fax()`, आप `मुद्रण योग्य`, `Sannable`, और `Faxable` में विभाजित हैं। वर्ग आरेख से पता चलता है कि एक `BasicPrinter` केवल `मुद्रण योग्य` लागू करता है, जबकि `AdvancedPrinter` सभी तीनों को लागू करता है। यह दृष्टिकोण इंटरफेस को दुबला रखता है और ग्राहकों को अप्रासंगिक संचालन पर निर्भर होने के लिए मजबूर होने से रोकता है।

निर्भरता उलटा सिद्धांत और निर्भरता आरेख

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

एक पैकेज निर्भरता आरेख में, आप निर्भरता की दिशा दिखा सकते हैं। यदि एक उच्च स्तरीय पैकेज सीधे एक निम्न स्तर के पैकेज पर इंगित करता है, तो आरेख एक डीआईपी उल्लंघन की चेतावनी देता है। समाधान उच्च स्तर के पैकेज में एक अमूर्तता (इंटरफेस) पेश करना है, जिसमें उस अंतरफलक के आधार पर निम्न स्तर के पैकेज के साथ। अद्यतन आरेख रिवर्स निर्भरता को दर्शाता है - SOLID अनुरूपता का एक स्पष्ट संकेत।

SOLID आर्किटेक्चर के लिए UML आरेख बनाने के लिए सर्वश्रेष्ठ अभ्यास

इन दिशानिर्देशों को स्वच्छ, सूचनात्मक UML आरेखों का उत्पादन करने के लिए देखें जो SOLID सिद्धांतों को मजबूत करते हैं:

  • ]Use stereotypes and Note: लागू करें `<>`, `<]>`, और `<]>` स्टीरियोटाइप डिजाइन निर्णयों को समझाने के लिए नोट्स जोड़ें, जैसे कि क्लास में केवल एक ही जिम्मेदारी क्यों है।
  • Keep आरेख केंद्रित:एक एकल आरेख को एक सिद्धांत या संबंधित सिद्धांतों का एक छोटा सेट को संबोधित करना चाहिए। हर वर्ग को एक विशाल आरेख में cramming से बचें।
  • ]केवल प्रासंगिक संबंध का वर्णन: विरासत, संघ, एकत्रीकरण और निर्भरता तीर दिखाएं जहां वे मामले में हैं। असंबंधित तीरों के साथ अतिभारित SOLID अनुपालन को अस्पष्ट करता है।
  • Highlight उल्लंघन: समस्याग्रस्त संबंधों को चिह्नित करने के लिए विभिन्न रंगों या छींक लाइनों का उपयोग करें। उदाहरण के लिए, उच्च स्तर से निम्न स्तर के कोड तक एक लाल निर्भरता तीर एक डीआईपी उल्लंघन को ध्वजांकित कर सकता है।
  • ]Refactoring के साथ iterate: जैसा कि आप SOLID से मिलने के लिए डिज़ाइन को फिर से तैयार करते हैं, आरेख को अद्यतन करते हैं। UML एक जीवित कलाकृति है - इसे कोड के लिए एक साथी के रूप में व्यवहार करते हैं, एक बार स्केच नहीं।

Them से बचने के लिए कैसे

यहां तक कि अनुभवी डेवलपर्स ने SOLID आर्किटेक्चर को डिजाइन करने के लिए UML का उपयोग करते समय जाल में पड़ सकते हैं।

  • ]Over-abstracting first: बहुत सारे इंटरफेस या कक्षाओं के साथ शुरू होने से yagni (आप नहीं Gonna Need it) का उल्लंघन हो सकता है। एक साधारण वर्ग आरेख के साथ शुरू, फिर केवल अमूर्तता को जोड़ते हैं जब SOLID सिद्धांतों द्वारा आवश्यक हो - आम तौर पर पुनर्निर्माण के दौरान।
  • Confusing UML नोटेशन: Misusing arrow प्रकार (जैसे, एक सामान्यीकरण तीर का उपयोग करते हुए जहां एक निर्भरता तीर सही है) misinterpretation का कारण बन सकता है। अध्ययन UML 2.5 विनिर्देश बुनियादी बातें अस्पष्टता से बचने के लिए। OMG UML विनिर्देश निश्चित संदर्भ है।
  • ]]] अनुक्रम आरेख में LSP को पहचानना: अनुक्रम आरेख रनटाइम इंटरेक्शन दिखाते हैं। यदि एक उपश्रेणी वस्तु को आधार वर्ग वस्तु के लिए प्रतिस्थापित किया जाता है और अप्रत्याशित रूप से बातचीत में बदलाव किया जाता है, तो LSP टूट जाता है। उपश्रेणी के उदाहरणों के साथ अनुक्रम मान्य करें।
  • ]Neglecting निर्भरता दिशा: DIP निर्भरता दिशा के बारे में है। पैकेज आरेख में, हमेशा ग्राहक से सर्वर तक तीर खींचते हैं। यदि आप चक्र या तीर गलत तरीके से इंगित करते हैं, तो अमूर्तता को फिर से तैयार करें।
  • Making आरेख बहुत विस्तृत: एक वर्ग आरेख हर गेट्टर और सेट्टर को देखने को दिखा रहा है। सार्वजनिक इंटरफेस और मुख्य संबंधों पर ध्यान केंद्रित करें जो SOLID सिद्धांतों को लागू करते हैं।

UML आरेख बनाने के लिए उपकरण

कई उपकरण आपको UML आरेख बनाने में मदद कर सकते हैं जो कोड के साथ सिंक्रनाइज़ किए गए हैं। एक चुनें जो आपके वर्कफ़्लो को फिट करता है:

  • PlantUML: एक पाठ आधारित आरेखण उपकरण जो संस्करण नियंत्रण के साथ एकीकृत करता है। सादे पाठ विवरण लिखें और आरेख को स्वचालित रूप से उत्पन्न करें। उन टीमों के लिए आदर्श जो कोड के रूप में आरेख चाहते हैं। ]PlanUML]] पर अधिक जानें।
  • Draw.io (diagrams.net) : A free, web-based आरेख संपादक. समर्थन UML stencils और आसान निर्यात. सहयोगात्मक व्हाइटबोर्डिंग के लिए अच्छा है।
  • ]Lucidchart: UML टेम्पलेट्स और वास्तविक समय सहयोग के साथ एक भुगतान मंच। संगम और जेरा के साथ एकीकरण प्रदान करता है।
  • Modelio: एक ओपन सोर्स मॉडलिंग टूल जो UML और BPMN का समर्थन करता है। क्लास आरेखों से कोड उत्पन्न कर सकता है और मौजूदा कोड को रिवर्स-इंजीनियर कर सकता है।
  • ]IntelliJ IDEA अल्टीमेट: में कक्षा, पैकेज और निर्भरता आरेख के लिए अंतर्निहित आरेखण विशेषताएं शामिल हैं। सीधे अपने कोडबेस के साथ लाइव सिंक्रनाइज़ेशन के लिए काम करता है।

SOLID सिद्धांतों और UML एकीकरण की गहरी समझ के लिए, आप रॉबर्ट सी मार्टिन के मूल लेखन को पर संदर्भित कर सकते हैं OOD (PDF) और विकिपीडिया लेख ]]SOLID सिद्धांतों ]]]]] पर।

निष्कर्ष

UML आरेख अमूर्त SOLID सिद्धांतों को ठोस दृश्य मॉडल में बदल देता है जो डेवलपर्स का निरीक्षण, चर्चा और सुधार कर सकता है। SRP और ISP के लिए उपयुक्त आरेख प्रकार - वर्ग आरेखों के लिए प्रत्येक सिद्धांत को मैप करके, OCP और DIP के लिए घटक आरेख, और LSP के लिए विरासत पदानुक्रम - आप व्यवस्थित रूप से सत्यापित कर सकते हैं कि आपकी वास्तुकला लचीला, रखरखाव योग्य और स्केलेबल बनी हुई है।

कुंजी UML का उपयोग एक नौकरशाही कलाकृति के रूप में नहीं बल्कि एक जीवित उपकरण के रूप में किया जाता है जो आपके कोड के साथ विकसित होता है। स्वचालित आरेख पीढ़ी और नियमित कोड समीक्षा के साथ संयुक्त, UML एक शक्तिशाली सहयोगी बन जाता है जो SOLID-compliant सिस्टम के निर्माण में जो समय की परीक्षा को खड़ा करता है।