आधुनिक जावास्क्रिप्ट विकास में डिजाइन पैटर्न

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

यदि एक टीम में कम से कम दो डेवलपर्स पैटर्न को समझते हैं, तो टीम के सामने समस्याओं को हल करने के बारे में बात करना बहुत उत्पादक हो जाता है। यदि टीम के केवल एक सदस्य को पैटर्न के बारे में पता है, तो यह आमतौर पर यह स्पष्ट करने के लिए होता है कि वह टीम के अन्य सदस्यों को क्या जानता है।



इस लेख का उद्देश्य सॉफ्टवेयर विकास के क्षेत्र में ज्ञान की एक तरह की औपचारिक प्रस्तुति के साथ पाठकों को रुचि देना है, उन्हें डिजाइन पैटर्न का विचार दिखाना और कई पैटर्न का वर्णन करना है जो दिलचस्प हैं कि वे आधुनिक जावास्क्रिप्ट विकास में आवेदन पाते हैं।

सिंगलटन पैटर्न

▍ सामान्य

डिजाइन पैटर्न "सिंगलटन" (जिसे "सिंगलटन" भी कहा जाता है) को सबसे व्यापक रूप से उपयोग किए जाने वाले पैटर्न में से एक नहीं कहा जा सकता है, लेकिन हम उसके साथ बातचीत शुरू करते हैं, क्योंकि यह समझना अपेक्षाकृत आसान है।

यह पैटर्न एक सिंगलटन की गणितीय अवधारणा से बढ़ता है - एक सिंगलटन सेट, अर्थात, एक सेट जिसमें केवल एक तत्व होता है। उदाहरण के लिए, सेट {null} एक सिंगलटन है।

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


जब हमारे पास बैटमैन है तो एक और सुपर हीरो क्यों?

ऊपर एक वर्ग का एक उदाहरण है जो सिंगलटन पैटर्न को लागू करता है।

Needed इसकी आवश्यकता क्यों है?

यह स्पष्ट है कि यह पैटर्न हमें केवल एक "सुपर हीरो" तक सीमित रखने की अनुमति देता है (यह स्पष्ट रूप से बैटमैन है)। लेकिन उसे इसकी आवश्यकता क्यों हो सकती है?

यद्यपि यह पैटर्न अपनी समस्याओं के बिना नहीं है (पहले इसे बुराई कहा जाता था, यह देखते हुए कि सिंगलटन को पैथोलॉजिकल लियर्स कहा जाता है), यह, कुछ स्थितियों में, बहुत उपयोगी हो सकता है। इन स्थितियों में से एक कॉन्फ़िगरेशन ऑब्जेक्ट्स को इनिशियलाइज़ करना है। एक विशिष्ट एप्लिकेशन में, यह इस तरह के ऑब्जेक्ट का केवल एक उदाहरण रखने के लिए समझ में आता है, जब तक कि परियोजना की सुविधाओं के अनुसार, इसमें कई समान वस्तुओं का उपयोग नहीं किया जाता है।

▍क्या इसका उपयोग करना है?

बड़े लोकप्रिय चौखटे में सिंगलटन पैटर्न का उपयोग करने का मुख्य उदाहरण कोणीय सेवाएं हैं। कोणीय दस्तावेज में एक अलग पृष्ठ है जो यह बताता है कि किसी सेवा को एक सिंगलटन कैसे बनाया जाए।

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

एक उदाहरण पर विचार करें। मान लीजिए कि हमारे पास एक साधारण एप्लिकेशन है जिसका उपयोग बटनों पर क्लिक की संख्या को गिनने के लिए किया जाता है।


प्रत्येक बटन पर क्लिक करने पर काउंटर अपडेट हो जाता है

बटन पर क्लिकों की संख्या को एक वस्तु में संग्रहित किया जाना चाहिए, जो निम्नलिखित विशेषताओं को लागू करता है:

• यह आपको बटन पर क्लिक की गणना करने की अनुमति देता है।
• यह क्लिक काउंटर के वर्तमान मूल्य को पढ़ना संभव बनाता है।

यदि ऐसी वस्तु एक सिंगलटन नहीं थी (और प्रत्येक बटन के पास ऐसी वस्तु का अपना उदाहरण है), तो प्रोग्राम बटन पर क्लिक की संख्या की गलत गणना करेगा। इसके अलावा, इस दृष्टिकोण के साथ, निम्नलिखित समस्या को हल करना आवश्यक है: "क्लिक को गिनने के लिए जिम्मेदार किसी विशेष वस्तु से स्क्रीन पर प्रदर्शित डेटा लिया जाएगा?"

ऑब्जर्वर पैटर्न

▍ सामान्य

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

इस पैटर्न को समझना मुश्किल नहीं है यदि आप वास्तविक दुनिया में इसकी उपमा पाते हैं। अर्थात्, हम अखबार की सदस्यता के बारे में बात कर रहे हैं।

मान लीजिए आप आमतौर पर एक कियोस्क पर समाचार पत्र खरीदते हैं। आप वहां जाते हैं, पूछते हैं कि क्या आपके पसंदीदा अखबार का एक ताजा मुद्दा है। यदि आपको जो चाहिए वह कियोस्क में नहीं है, तो आप घर जाते हैं, समय बर्बाद कर रहे हैं और फिर दोबारा कियोस्क पर जाएं। यदि हम इस स्थिति को जावास्क्रिप्ट के लिए लागू मानते हैं, तो यह किसी इकाई के चक्रीय चुनाव की तरह होगा, जब तक कि इसके लिए आवश्यक डेटा प्राप्त न हो जाए।

आखिरकार, जब आपको अंततः अखबार की आवश्यकता होती है, तो आप इस बात के लिए आगे बढ़ सकते हैं कि आप इस समय के लिए क्या प्रयास कर रहे हैं - एक कप कॉफी लें और अखबार का विस्तार करें। जावास्क्रिप्ट में, यह कॉलबैक कॉल करने के लिए समान होगा, जिसे हम वांछित परिणाम प्राप्त करने के बाद कॉल करने जा रहे हैं।


अंत में आप अखबार पढ़ सकते हैं

ऐसा करना अधिक उचित होगा: एक समाचार पत्र की सदस्यता लें और हर दिन इसका नवीनतम अंक प्राप्त करें। इस दृष्टिकोण के साथ, प्रकाशक आपको बताएगा कि समाचार पत्र का एक ताजा अंक जारी किया गया है और इसे आप तक पहुंचाएं। अब आपको कियोस्क पर नहीं जाना होगा अधिक समय बर्बाद नहीं करना।

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


अब आप अपने पसंदीदा सुबह के अखबार को कभी नहीं छोड़ेंगे

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

Needed इसकी आवश्यकता क्यों है?

पैटर्न "पर्यवेक्षक" का उपयोग कई स्थितियों में किया जाता है, लेकिन आमतौर पर इसका उपयोग तब किया जाना चाहिए जब आप वस्तुओं के बीच एक-से-कई संबंध बनाना चाहते हैं, और साथ ही, ऐसी वस्तुओं को दृढ़ता से नहीं जोड़ा जाना चाहिए। इसके अलावा, सिस्टम को कुछ परिवर्तनों के बारे में असीमित संख्या में वस्तुओं को सूचित करने में सक्षम होना चाहिए।

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

यह संभावना है कि आप पहले से ही डिजाइन का उपयोग कर चुके हैं जो पर्यवेक्षक पैटर्न से मिलते जुलते हैं। उदाहरण के लिए, यह addEventListener । किसी ईवेंट श्रोता को एक तत्व में जोड़ना प्रेक्षक पैटर्न का उपयोग करने के सभी संकेत हैं:

• आप ऑब्जेक्ट को सब्सक्राइब कर सकते हैं।
• आप ऑब्जेक्ट से सदस्यता समाप्त कर सकते हैं।
• एक वस्तु अपने सभी ग्राहकों को घटना के बारे में सूचित कर सकती है।

इस अर्थ में "पर्यवेक्षक" पैटर्न के अस्तित्व के बारे में जानना उपयोगी है कि यह ज्ञान आपको इस पैटर्न का उपयोग करके मौजूदा समाधान का पता लगाने के लिए अपने स्वयं के विषय, या पहले की तुलना में बहुत तेजी से महसूस करने की अनुमति देता है।

▍क्या इसका उपयोग करना है?

इस पैटर्न का मूल कार्यान्वयन विशेष रूप से जटिल नहीं है, लेकिन उत्कृष्ट पुस्तकालय हैं जो इसे लागू करते हैं और कई परियोजनाओं में उपयोग किए जाते हैं। हम रिएक्टिवएक्स प्रोजेक्ट, और आरएक्सजेएस के इसके जावास्क्रिप्ट संस्करण के बारे में बात कर रहे हैं।

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

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

मुखौटा पैटर्न

▍ सामान्य

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

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

Needed इसकी आवश्यकता क्यों है?

"मुखौटा" पैटर्न का उपयोग बड़ी संख्या में स्थितियों में किया जा सकता है, जिनके बीच हम विशेष रूप से उन पर ध्यान दे सकते हैं जब वे कोड को समझने में आसान बनाने की कोशिश करते हैं (यानी, वे सरल एपीआई के पीछे जटिल तंत्र छिपाते हैं), और जब सिस्टम के टुकड़े यथासंभव संभव हो जाते हैं। एक दूसरे से जुड़े हुए।


इन वस्तुओं को ड्रैगन की मांद से कुछ चाहिए।

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

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

▍क्या इसका उपयोग करना है?

मोहरा पैटर्न अक्सर कोणीय में पाया जाता है। वहाँ, सेवाओं को कुछ बुनियादी तर्क को सरल बनाने के लिए एक साधन के रूप में उपयोग किया जाता है। लेकिन यह पैटर्न न केवल कोणीय में लागू है, नीचे आप इसे देख सकते हैं।

मान लें कि हमें एप्लिकेशन में एक राज्य प्रबंधन प्रणाली जोड़ने की आवश्यकता है। इस समस्या को हल करने के लिए, आप विभिन्न उपकरणों का उपयोग कर सकते हैं, उनमें से - Redux, NgRx, Akita, MobX, Apollo, साथ ही - लगातार उभरते नए उपकरण। क्यों नहीं उन सब की कोशिश?
मुख्य कार्यक्षमता क्या है जो एक राज्य प्रबंधन पुस्तकालय प्रदान करना चाहिए? ये संभवतः निम्नलिखित विशेषताएं हैं:

• राज्य प्रबंधन प्रणाली को सूचित करने के लिए एक तंत्र जिसे हमें राज्य को बदलने की आवश्यकता है।
• वर्तमान स्थिति या इसके टुकड़े को प्राप्त करने का तंत्र।

यह सब इतना बुरा नहीं लगता है।

अब, "मुखौटा" पैटर्न से लैस, आप राज्य के विभिन्न हिस्सों के साथ काम करने के लिए facades लिख सकते हैं, सुविधाजनक एपीआई प्रदान कर सकते हैं जो कार्यक्रम में उपयोग किया जा सकता है। उदाहरण के लिए, facade.startSpinner() , facade.stopSpinner() और facade.getSpinnerState() जैसे कुछ। ऐसे तरीकों को समझना आसान है, आप कार्यक्रम के बारे में बातचीत में उन्हें आसानी से संदर्भित कर सकते हैं।

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


अनुप्रयोग की स्थिति को प्रबंधित करने के लिए अलग-अलग प्रणालियाँ, जिन्हें एक ही मोहरे के माध्यम से पहुँचा जा सकता है, वे भी ड्रेगन हो सकते हैं ...

परिणाम

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

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

प्रिय पाठकों! आप किस डिज़ाइन पैटर्न का उपयोग करते हैं?