के लिए डिजाइन पैटर्न क्या हैं?

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

युवाओं की कुछ यादें

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

लेकिन बेवकूफ लोग डिजाइन पैटर्न के साथ नहीं आए:

• 70 के दशक में , आर्किटेक्ट क्रिस्टोफर अलेक्जेंडर ने व्यवसाय शुरू किया और डिजाइन पैटर्न का एक सेट तैयार किया।
• आईटी में उनका मामला 1987 में कुख्यात केंट बैक और वार्ड कनिंघम द्वारा उठाया गया था, जो लोकप्रिय स्मॉलटाक प्रोग्रामिंग भाषा के लिए डिजाइन पैटर्न का संकलन करता है।
• एक अन्य दिग्गज आईटी व्यक्ति, एरिक गामा ने 1988-1990 में इस विषय पर डॉक्टरेट शोध प्रबंध लिखा था।
• और अंत में, 90 के दशक की शुरुआत में, प्रसिद्ध "गैंग ऑफ़ फोर" एक ही एरिच गामा, रिचर्ड हेल्म, राल्फ जॉनसन और जॉन व्लिसिडसोम ने प्रसिद्ध पुस्तक "डिज़ाइन पैटर्न: एलिमेंट ऑफ़ ऑब्जेक्टिव ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर" प्रकाशित किया।

ऐतिहासिक कालक्रमों को जारी रखने में कोई समझदारी नहीं है। यह पहली पुस्तक थी जिसमें से हमारी पीढ़ी ने डिजाइन पैटर्न पर अपने ज्ञान को आकर्षित किया और उन्हें अपने काम में लागू करने की कोशिश की। वह इस विषय में एक क्लासिक मानी जाती है और इसे अवश्य पढ़ें।

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

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

और बिना टेम्पलेट के कैसे?

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

पहला महत्वपूर्ण पैरामीटर निर्णय लेने और निर्णय लेने में बिताया गया समय है (मुझे उम्मीद है कि आपके पास एक से अधिक दाढ़ी वाले वरिष्ठ वरिष्ठ वैश्विक उत्पाद सॉफ़्टवेयर आर्किटेक्ट निर्णय ले रहे हैं )। कल्पना कीजिए कि डेकोरेटर को लागू करने के लिए किसी व्यक्ति को कितनी जल्दी समझाना मुश्किल होगा: “हमें एक वर्ग बनाने की ज़रूरत है, जिसमें हम कंस्ट्रक्टर में एक ही इंटरफ़ेस के दूसरे कार्यान्वयन का एक उदाहरण पारित करेंगे और जो इन बुनियादी व्यवहार को बदलने के बिना इन विधियों के कॉल में तर्क जोड़ देगा। .. "लेकिन फिर भी पर्दे के पीछे छोटी-छोटी बातों और बारीकियों का एक समूह बना रहा। और यह आपके डिज़ाइन के छोटे विवरणों के लिए है, जो कि अधिकांश निर्णयों में दर्जनों या सैकड़ों हैं। हम जटिल और गंभीर वास्तुशिल्प पैटर्न को भी नहीं छूते हैं।

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

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

जीवन में, हम स्थितियों, वस्तुओं और कार्यों का वर्णन करने के लिए सक्रिय रूप से उदाहरणों का उपयोग करते हैं। किसी को कुछ अवधारणा समझाने के लिए, हम प्रसिद्ध ज्ञान पर आधारित हैं और उनके आधार पर उदाहरण बनाते हैं। "वासी के रूप में स्वस्थ", "जॉगिंग के 5 किमी बाद जितना कठिन", "हैंगओवर से उतना ही बुरा", "नींबू जैसा खट्टा", आदि। हम अपने भाषण में समान भावों का लगातार उपयोग करते हैं और इसे नोटिस भी नहीं करते हैं। हमारे लिए, उनका उपयोग विस्तृत विवरण की तुलना में आसान है और यह आपके वार्ताकार को आपको बेहतर समझने की अनुमति देता है।

अगला स्तर

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

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

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

निष्कर्ष

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

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