SOLID वास्तुकला (रॉबर्ट मार्टिन के लेखकत्व) के विकास के सिद्धांतों के विवरण और व्याख्या के साथ एक समस्या है। कई स्रोत अपनी परिभाषा और यहां तक कि उनके उपयोग के उदाहरण भी देते हैं। उनका अध्ययन करना और खुद का उपयोग करने की कोशिश करना, मैंने लगातार खुद को यह सोचते हुए पकड़ा कि उनके आवेदन के जादू की पर्याप्त व्याख्या नहीं थी। और आंतरिक गियर को देखने की कोशिश कर रहा है, समझने के लिए - और मेरे लिए यह याद रखने का मतलब है - उन्हें अपनी "शर्तों-अलमारियों" में बाहर रखा। खैर, अगर यह किसी और के लिए उपयोगी होगा।
हम उपरोक्त डिजाइन दृष्टिकोण के "अलमारियों को टकराने" के लिए आगे बढ़ते हैं।
एकल जिम्मेदारी सिद्धांत (एसआरपी) एकमात्र जिम्मेदारी सिद्धांत
एक लक्ष्य के कार्यान्वयन के दौरान केवल एक कोड को बदलना चाहिए। यदि कोड का एक टुकड़ा दो कार्यों को लागू करता है और विभिन्न उपयोगों के लिए बदलता है, तो आपको प्रत्येक उद्देश्य के लिए कॉपी के इस टुकड़े की नकल करनी चाहिए। यह बहुत महत्वपूर्ण है क्योंकि इसे दोहराव को खत्म करने के आम तौर पर स्वीकृत सिद्धांत से प्रस्थान की आवश्यकता होती है।
इस सिद्धांत का उद्देश्य इस तथ्य के कारण शुरू की गई अंतर्निहित त्रुटियों को समाप्त करना है कि एक कोड अनुभाग, प्रक्रिया, वर्ग, घटक (इसके बाद, शब्द [घटक] इन अवधारणाओं को संयोजित करने के लिए उपयोग किया जाता है) के विकास के लिए निम्नलिखित अपरिवर्तनीय मौजूद हैं:
- [1] सही ढंग से लिखा गया [घटक] आवश्यक रूप से उपयोग किया जाता है और अधिक बार कई बार,
- [२] उपयोग के प्रत्येक स्थान पर, [घटक] एक सुसंगत व्यवहार को बनाए रखने की अपेक्षा की जाती है, जो एक परिणामी परिणाम की ओर ले जाता है,
- [3] कई स्थानों पर [घटक] का उपयोग करते समय, परिणाम को उपयोग के प्रत्येक स्थान को संतुष्ट करना चाहिए,
- यदि उपयोग के स्थानों में से एक में [घटक] बदलाव आवश्यक है, और उपयोग के किसी अन्य स्थान के लिए [घटक] के पिछले व्यवहार की आवश्यकता है, तो [घटक] की एक प्रति बनाना आवश्यक है और फिर इसे संशोधित करें (या सामान्य पैरामीटर [अतिरिक्त मानकों के लिए जो अलग-अलग व्यवहार प्रदान करते हैं)।
अगर [घटक] के उपयोग के स्थान हैं जो प्रोग्रामर द्वारा हल किए गए वर्तमान कार्य के लिए महत्वपूर्ण नहीं हैं, तो उसके लिए इस [घटक] में किए गए परिवर्तनों के उपयोग के इन स्थानों के साथ संगतता की जांच करना भूल जाना बहुत आसान है।
इसलिए, उपयोग के सभी स्थानों को एक ही जिम्मेदारी के [एकल जिम्मेदारी] क्षेत्र में स्थित होना चाहिए, अर्थात, प्रोग्रामर द्वारा हल की गई किसी भी समस्या के लिए एक बार में बदल दिया जाए और इसे ध्यान में रखा जाए)।
सिद्धांत कोड के एक भाग और एक घटक, पुस्तकालय, कार्यक्रम, कई स्थानों पर उपयोग किए जाने वाले कार्यक्रमों के सेट दोनों पर लागू होता है।
कई स्रोत एसआरपी के आदर्श के रूप में केवल एक "फ़ंक्शन" के साथ एक वर्ग का उदाहरण देते हैं और "दिव्य वस्तु" के वर्ग के रूप में, आवेदन के सभी कार्यों को एक एंटीपैटर्न के रूप में मिलाते हैं। केवल एक "फ़ंक्शन" के साथ एक IMHO वर्ग कोड आर्किटेक्चर के समय से पहले अनुकूलन के लिए एक आवश्यकता है, कई वर्गों (कोड संस्थाओं) को खरोंच से लिखने के लिए प्रेरित करते हुए, यह भूल जाते हैं कि उपयोग की एक से अधिक जगह की अनुपस्थिति प्रोग्रामर को स्थानीय रूप से (एक कक्षा में) एक छोटी राशि का मूल्यांकन करने की अनुमति देती है। असमान कोड संस्थाओं के बाहरी संबंधों का विश्लेषण करने के लिए उनके "फ़ंक्शन" के लिए जिम्मेदार कोड की तुलना करना। एक छोटे से अनुप्रयोग के लिए एक "दिव्य वस्तु" भी एक मजबूत अपराध नहीं है - यह आपको विकास शुरू करने की अनुमति देता है: सभी आवश्यक संस्थाओं का चयन करें और, उन्हें पक्ष लिखकर, मानक पुस्तकालय और बाहरी मॉड्यूल की बाहरी वस्तुओं से अलग करें (एक जीवित कोशिका बनाएं और एक झिल्ली के साथ अलग करें)। परियोजना की वृद्धि और विकास की प्रक्रिया में, एसआरपी का पालन करने में मदद करने वाले कई तरीके हैं, उनमें से एक वर्गों में विभाजन है और "कार्यों" की संख्या को कम करना है जिसके लिए प्रत्येक वर्ग जिम्मेदार है (शरीर में कोशिका विभाजन और उनकी विशेषज्ञता)।
यहां मैं SRP को बनाए रखने के लिए तकनीकों का एक सेट लिखना चाहता हूं, लेकिन यह काम अभी तक पूरा नहीं हुआ है (मुझे आशा है कि "हाथ पहुंचेंगे")। स्पष्ट क्षेत्रों से जहाँ आप इन तरकीबों को देख सकते हैं:
- डिजाइन पैटर्न;
- विभिन्न विशेष घटक शाखाओं का उपयोग करते हुए, एक घटक बनाने के लिए जो सभी एप्लिकेशन विधियों (गीथहब पर कांटा) को संतुष्ट करता है।
ओपन-क्लोज्ड सिद्धांत (OCP) ओपन / क्लोज्ड सिद्धांत
यह कोड के विकास की योजना बनाने के लिए इष्टतम है ताकि प्रोग्रामर के लिए नए कार्यों को लागू करने के लिए नए कोड को जोड़ना आवश्यक हो, जबकि पुराने कोड को परिवर्तनों की आवश्यकता नहीं है। कोड को बदलने के लिए (बंद) बंद और खोलने के लिए (ओपन) कोड होना चाहिए।
इस सिद्धांत का उद्देश्य श्रम लागत को कम करना है और विकास में निम्नलिखित असावधानियों के कारण शुरू की गई अंतर्निहित त्रुटियों को समाप्त करना है:
- [१], [२], [३] पहले वर्णित,
- एक नया कार्य लागू करने के लिए, प्रोग्रामर नए [घटकों] को जोड़ सकता है या पुराने [घटकों] के व्यवहार को बदल सकता है,
- [घटक] के अतिरिक्त को नए उपयोग के स्थान पर सत्यापन की आवश्यकता होती है, और प्रोग्रामर के समय का खर्च होता है
- नए कार्य के कारण [घटक] के व्यवहार में परिवर्तन के लिए नए उपयोग के स्थान पर और पुराने उपयोग के सभी स्थानों पर सत्यापन की आवश्यकता होती है, जो प्रोग्रामर के समय की खपत का भी कारण बनता है, और प्रकाशित [घटक] के मामले में, उन सभी प्रोग्रामों का कार्य जो [घटक] का उपयोग करते हैं।
प्रोग्रामर द्वारा खर्च किए गए समय को कम करते हुए एक नए कार्य को लागू करने के लिए एक विकल्प चुनना उचित है।
अधिक बार सॉफ्टवेयर विकास के अभ्यास में, जोड़ने की लागत परिवर्तन की लागत की तुलना में बहुत कम है, जो स्पष्ट रूप से [ओपन-क्लोज्ड] सिद्धांत का उपयोग करने का लाभ देता है। इसी समय, राज्य में कार्यक्रम की वास्तुकला को बनाए रखने के लिए बहुत सारी तकनीकें हैं जहां एक नए कार्य का कार्यान्वयन केवल [घटकों] को जोड़ने के लिए नीचे आता है। वास्तुकला के साथ इस काम के लिए एक प्रोग्रामर के समय की भी आवश्यकता होती है, लेकिन बड़ी परियोजनाओं में अभ्यास पुरानी प्रक्रियाओं के दृष्टिकोण का उपयोग करने की तुलना में बहुत कम दिखाता है। और, ज़ाहिर है, विकास का यह वर्णन आदर्शीकरण है। सिर्फ जोड़ने या बदलने से कार्य का लगभग कोई कार्यान्वयन नहीं होता है। वास्तविक जीवन में, इन तरीकों के मिश्रण का उपयोग किया जाता है, लेकिन ओसीपी ऐड दृष्टिकोण का उपयोग करने के लाभ पर जोर देता है।
और यहाँ मैं OCP को बनाए रखने के लिए तकनीकों का एक सेट लिखना चाहूंगा। स्पष्ट क्षेत्रों से जहाँ आप इन तरकीबों को देख सकते हैं:
- डिजाइन पैटर्न;
- dll पुस्तकालयों और उनके वितरण, अद्यतन और कार्यक्षमता के विकास के लिए विकल्प;
- COM पुस्तकालयों और उनमें वस्तुओं का विकास;
- प्रोग्रामिंग भाषाओं का विकास और पहले से लिखे गए कोड के लिए समर्थन;
- राज्य की विधायी प्रणाली का विकास करना।
Liskov प्रतिस्थापन सिद्धांत (LSP) बारबरा Liskov प्रतिस्थापन सिद्धांत
यह सिद्धांत आधार इंटरफ़ेस [आधार] के विस्तार के उपयोग को सीमित करता है, जिसमें कहा गया है कि आधार इंटरफ़ेस के प्रत्येक कार्यान्वयन में आधार इंटरफ़ेस के रूप में व्यवहार होना चाहिए। उसी समय, मूल इंटरफ़ेस इसके उपयोग के स्थानों में अपेक्षित व्यवहार को ठीक करता है। और बेस इंटरफ़ेस द्वारा तय किए गए अपेक्षित व्यवहार से अंतर के कार्यान्वयन व्यवहार में उपस्थिति, अपरिवर्तनीय [2] के उल्लंघन की संभावना को जन्म देगी।
यह सिद्धांत आधारित है और अमूर्तता के आधार पर डिजाइन तकनीक को परिष्कृत करता है। इस दृष्टिकोण में, एक अमूर्तता पेश की जाती है - कुछ बुनियादी गुणों और कई स्थितियों की व्यवहार विशेषता तय की जाती है। उदाहरण के लिए, [घटक-प्रक्रिया] "स्थितियों के लिए पिछली स्थिति में जाएं": "पाठ में कर्सर", "एक शेल्फ पर बुक", "एक सरणी में तत्व", "नृत्य में पैर", आदि और इस [घटक] को सौंपा अक्सर रोजमर्रा के अनुभव और औपचारिकता के बिना) कुछ आवश्यक शर्तें और व्यवहार, उदाहरण के लिए: "एक चल वस्तु की उपस्थिति", "कई बार दोहराएं", "तत्वों के आदेश की उपस्थिति", "तत्वों के निर्धारित पदों की उपस्थिति"। एलएसपी के लिए आवश्यक है कि [घटक] के लिए एक नई उपयोग की स्थिति जोड़ते समय आधार की सभी आवश्यक शर्तें और सीमाएं पूरी हों। और स्थिति "एक चीनी में अनाज" को इस अमूर्तता द्वारा वर्णित नहीं किया जा सकता है, हालांकि अनाज, निश्चित रूप से, एक स्थिति है, ऐसे पद हैं जिनमें अनाज पहले रहे हैं, और उनमें इसे स्थानांतरित करना संभव है - तत्वों के केवल कुछ निश्चित स्थान हैं।
इस सिद्धांत का उद्देश्य विकास में निम्नलिखित असावधानियों के कारण शुरू की गई अंतर्निहित त्रुटियों को समाप्त करना है:
- [१], [२], [३] पहले वर्णित,
- बुनियादी [प्रक्रिया] एक व्यवहार का वर्णन करता है जो बड़ी संख्या में स्थितियों में उपयोगी होता है, इसकी प्रयोज्यता के लिए आवश्यक बाधाओं को निर्धारित करता है,
आधार के कार्यान्वयन के लिए विकसित [प्रक्रिया] को अपनी सभी सीमाओं को पूरा करना चाहिए, जिसमें हार्ड-ट्रैक किए गए निहित (अनौपचारिक रूप से प्रदान किए गए) शामिल हैं।
बहुत बार, इस सिद्धांत का वर्णन करने के लिए एक आयत ([आधार]) और एक वर्ग (कार्यान्वयन) के साथ एक उदाहरण दिया जाता है। स्थिति class CSquare : public CRectangle । [बेस] में, चौड़ाई और ऊंचाई (सेट (गेट)) चौड़ाई, सेट (गेट) ऊंचाई के साथ काम करने के लिए ऑपरेशन शुरू किए गए हैं। CSquare के कार्यान्वयन में, ये सेट ऑपरेशन ऑब्जेक्ट के दोनों आकारों को बदलने के लिए मजबूर हैं। मुझे हमेशा इस स्पष्टीकरण की कमी थी कि निम्नलिखित प्रतिबंध [आधार] में "अनौपचारिक रूप से" सेट है: "चौड़ाई, ऊंचाई का स्वतंत्र रूप से उपयोग करने की क्षमता।" CSquare कार्यान्वयन में, इसका उल्लंघन किया जाता है, और इस स्वतंत्रता के उपयोग के आधार पर कार्यों के एक सरल अनुक्रम का उपयोग करने के स्थानों में: r.SetWidth(r.GetWidth()*2); r.SetHeight(r.GetHeight()*2) r.SetWidth(r.GetWidth()*2); r.SetHeight(r.GetHeight()*2) - कार्यान्वयन के लिए, CSquare CRectangle के लिए ग्रहण किए गए 2 बार के बजाय दोनों आकारों को 4 गुना बढ़ा देगा।
IMHO यह सिद्धांत ऐसे अनौपचारिक बाधाओं पर नज़र रखने की कठिनाई को इंगित करता है, जो कि विकास के दृष्टिकोण "आधार-कार्यान्वयन" के उपयोग की महान उपयोगिता और उच्च आवृत्ति के साथ, विशेष ध्यान देने की आवश्यकता है।
इंटरफेस अलगाव का सिद्धांत (आईएसपी) इंटरफेस के अलगाव का सिद्धांत; निर्भरता उलटा सिद्धांत (DIP) निर्भरता उलटा सिद्धांत
ये दोनों सिद्धांत उनकी आवश्यकताओं के क्षेत्र में बहुत निकट हैं। दोनों अनुमानित रूप से सबसे छोटे संभव बुनियादी इंटरफ़ेस का उपयोग करने की उपयोगिता को प्रभावित करते हैं, दो [घटकों]: "क्लाइंट" और "सर्वर" की बातचीत के लिए एक उपकरण के रूप में - ये नाम केवल पहचान के लिए चुने गए हैं। इस मामले में, [घटकों] द्वारा उपयोग की जाने वाली सामान्य जानकारी आधार इंटरफ़ेस में केंद्रित है। एक [घटक] ("सर्वर") आधार इंटरफ़ेस के कार्यान्वयन को लागू करता है, अन्य [घटक] ("क्लाइंट") इस कार्यान्वयन को संदर्भित करता है।
इन सिद्धांतों के लिए लक्ष्य घटक निर्भरता को कम करना है, अगर यह अंतर्निहित इंटरफ़ेस को नहीं बदलता है, तो उनके कोड में स्वतंत्र परिवर्तन की अनुमति देता है। यदि घटक एसआरपी सिद्धांत की आवश्यकताओं को पूरा करते हैं, तो घटक परिवर्तनों की स्वतंत्रता जटिलता और श्रम को कम कर देती है। एक समान दृष्टिकोण संभव है क्योंकि विकास में निम्नलिखित हमलावर मौजूद हैं:
- [१], [२], [३] पहले वर्णित,
- प्रत्येक [घटक] अपने व्यवहार में निहित अपने उपयोग की सीमा बनाता है,
- [घटक] के उपयोग के प्रत्येक स्थान पर इसके सभी प्रतिबंध शामिल हो सकते हैं,
- मूल [घटक] परिभाषा के परिणाम में जटिलता कम होती है और [घटक] कार्यान्वयन की तुलना में प्रतिबंधों की संख्या होती है,
- [घटक] में कोई भी परिवर्तन इसकी सीमाओं को बदलता है और इसके उपयोग के सभी स्थानों के सत्यापन की आवश्यकता होती है, जो प्रोग्रामर के समय के खर्च का कारण बनता है,
आधार [घटक] के उपयोग के स्थानों को [घटक] कार्यान्वयन में परिवर्तन करने के बाद सत्यापन की आवश्यकता नहीं है।
यह स्पष्ट है कि अप्रयुक्त कार्यक्षमता और प्रतिबंधों को त्यागकर आधार इंटरफ़ेस के "आकार" को कम करना उचित है, जिससे (एलएसपी) के सिद्धांत द्वारा [घटक] कार्यान्वयन को सीमित किया जा सके।
आईएसपी का सिद्धांत "सर्वर" के इंटरफेस के अलगाव (अलगाव) की आवश्यकता पर जोर देता है, अगर इसके सभी प्रकाशित कार्यक्षमता का उपयोग इस "क्लाइंट" द्वारा नहीं किया जाता है। इस मामले में, केवल ग्राहक द्वारा आवश्यक [आधार] आवंटित किया जाता है और संयुक्त रूप से प्रतिबंधित जानकारी का न्यूनतमकरण सुनिश्चित किया जाता है।
और यहाँ मैं डीआईपी को बनाए रखने के लिए तकनीकों का एक सेट लिखना चाहूंगा। स्पष्ट क्षेत्रों से जहाँ आप इन तरकीबों को देख सकते हैं:
- सार्वजनिक और निजी भागों (और OOP के अन्य सिद्धांतों) में वर्ग विवरण को अलग करना,
- एक गतिशील पुस्तकालय के साथ बातचीत का विवरण सीमित कार्यों और ऑब्जेक्ट विवरणकों के समूह के साथ,
- एक पुस्तक पुस्तकालय का उपयोग करने के लिए एक इंटरफ़ेस के रूप में फाइल कैबिनेट का उपयोग करना।
शीर्ष पर लौटते हुए, मैं समझाऊंगा कि "समझ में नहीं" का चयन क्यों किया जाता है। लंबे समय से पीड़ित और बहुत ही IMHO उपयोगी नियम गलतियों से जोर देने के लिए नकारात्मकता को जोड़ा जाता है। यह बेहतर नहीं है और इसलिए तकनीक का उपयोग न करना, गलतफहमी की तुलना में, इसे विश्वास में लेना, प्रौद्योगिकी का उपयोग करने पर अपने संसाधनों को खर्च करना और परिणामस्वरूप, शालीनता के अलावा कोई उपयोगी निकास नहीं मिलता है और फैशनेबल तकनीक में भागीदारी के बारे में शेखी बघारने की संभावना नहीं है।
आपका ध्यान के लिए धन्यवाद।
संदर्भ