प्रोग्रामिंग डिज़ाइन पैटर्न को समझ नहीं सकते


16

मैं पिछले 4 वर्षों से जावास्क्रिप्ट के साथ काम कर रहा हूं। मैं अपनी समस्या को सुलझाने के कौशल के बारे में बहुत आश्वस्त हूं और मैं देख सकता हूं कि मेरी कोड गुणवत्ता में सुधार हो रहा है। मैं समुदाय के साथ अद्यतित रहने की कोशिश करता हूं और वर्तमान में ES2015 और React.js के साथ काम कर रहा हूं। हालाँकि, मुझे लगता है कि मैं प्रोग्रामिंग डिज़ाइन पैटर्न को बिल्कुल समझ नहीं सकता। मुझे पता है कि इस बारे में संसाधन कहां से मिलेंगे और मैंने पहले ही इसके बारे में किताबें पढ़ ली हैं। मैं प्रोजेक्ट संरचना के बारे में निर्णय लेने के लिए अपने वरिष्ठ सहकर्मियों पर निर्भर हूं लेकिन मुझे इस पर काम करने में कोई समस्या नहीं है।

जब भी मुझे अपने दम पर कुछ शुरू करने की आवश्यकता होती है, तो मैं इन दो रास्तों की तलाश करता हूं: यदि मैं किसी बड़े पुस्तकालय / ढांचे का उपयोग कर रहा हूं जैसे कि React.js, तो मैं इस बात की नकल करता हूं कि समुदाय क्या कर रहा है; यदि मैं कुछ छोटे पर हूं तो मैं मॉड्यूल पैटर्न का उपयोग करूंगा। मुझे पता है कि एक बार मुझे इस विषय पर बेहतर समझ मिल जाएगी तो मैं बेहतर निर्णय ले पाऊंगा, लेकिन अब मैं पूरी तरह से हार चुका हूं।

क्या मुझे इस पर बेहतर शिक्षा की तलाश करनी चाहिए? क्या मुझे इस विषय पर एक संरक्षक की आवश्यकता है? क्या मैं सिर्फ बेवकूफ हूं? क्या वास्तव में यह समझना मुश्किल है?


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

3
परियोजना का आकार भी महत्वपूर्ण भूमिका निभाता है।
मैथ्यू

2
@ मैथ्यू नाइटिक मुझे जरूरी नहीं कि जावा / सी # दृढ़ता से टाइप किया जाए ...
जेरेड स्मिथ

2
@JaredSmith सच है, मैं अक्सर दृढ़ता से टाइप किए गए और स्थैतिक रूप से टाइप किए गए भेद को भूल जाता हूं।
मैथ्यू

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

जवाबों:


34

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

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

डिजाइन पैटर्न के बारे में जानने के लिए कुछ महत्वपूर्ण बातें:

  1. कुछ डिजाइन पैटर्न प्रकृति में वास्तुशिल्प हैं। एमवीसी और एमवीवीएम ऐसे पैटर्न के उदाहरण हैं। आप ऐसे पैटर्न का उपयोग करते हैं जब आपको संगठनात्मक और संरचनात्मक लाभों की आवश्यकता होती है जो वे प्रदान करते हैं।

  2. कुछ डिज़ाइन पैटर्न प्रोग्रामिंग भाषाओं की कमियों के लिए वर्कअराउंड हैं। यदि आप एक अधिक अभिव्यंजक प्रोग्रामिंग भाषा का उपयोग करते हैं, तो आपको इन पैटर्नों की आवश्यकता नहीं होगी, लेकिन अक्सर आपको यह विकल्प नहीं मिलता है। के अधिकांश GOF पैटर्न हैं इस श्रेणी में

  3. सॉफ़्टवेयर पैटर्न का उपयोग केवल तब करें जब आप उस समस्या को हल करने का प्रयास कर रहे हैं जिसे पैटर्न विशेष रूप से हल करने के लिए डिज़ाइन किया गया है। यदि आप सॉफ़्टवेयर पैटर्न को एक साथ सिलाई करके एक एप्लिकेशन लिख रहे हैं, तो आप इसे गलत कर रहे हैं।

  4. अस्तित्व में हर कंप्यूटिंग समस्या के लिए एक मौजूदा सॉफ्टवेयर पैटर्न नहीं है। इस मामले में, प्रोग्रामिंग केवल एक पैटर्न-मिलान अभ्यास होगा।

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


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

1
गोफ पैटर्न 20 साल पुराना है। उनमें से अधिकांश C ++ के साथ समस्याओं को ठीक करने के लिए बनाए गए थे, जावा द्वारा विरासत में मिली समस्याएं, क्योंकि जावा C ++ पर आधारित है।
रॉबर्ट हार्वे

इस जवाब में विरोधाभास "अच्छी तरह से ज्ञात समस्या" हिस्सा है। यदि आपने उन्हें कभी अनुभव नहीं किया है, तो इन "अच्छी तरह से ज्ञात समस्याओं" को समझना मुश्किल है।
फ्यूहरमैनटर

2
जावा C ++ पर आधारित नहीं है । javas syntax C ++ से प्रेरित है, लेकिन निश्चित रूप से इसके आधार पर नहीं। दोनों भाषाएँ बहुत अलग तरह से काम करती हैं। इस तथ्य से कि जावा एबस्टैक्ट हार्डवेयर, मेमोरी का प्रबंधन स्वयं करता है, जिसमें टेम्प्लेट नहीं, बल्कि जेनरिक आदि शामिल हैं
पॉलिग्नोम

4

सीखने के लिए हर किसी का दृष्टिकोण थोड़ा अलग है, और मुझे नहीं पता कि आपका सामान्य दृष्टिकोण क्या है, लेकिन मेरा मानना ​​है कि अपने आप को "बेवकूफ" के रूप में लेबल करके अपने आप को एक असहमति है।

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

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

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

इसलिए, मेरी सामान्य सलाह है कि यदि आपको लगता है कि आपका दृष्टिकोण गलत है, तो इसे बदल दें। अपने आस-पास के लोगों को देखें जो आपको लगता है कि आप उस सामग्री को सीख रहे हैं जो आपको लगता है कि आप लोभी नहीं हैं और वे जो कर रहे हैं उसे देखें या उनसे पूछें।


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

@ AdrianIftode - सहमत हैं। जैसा कि उल्लेख किया गया है, मैं पुस्तकों, ब्लॉगों या किसी भी पठन सामग्री पर छूट नहीं दूंगा, लेकिन यह एक सामान्य समस्या है जिसे मैंने प्रोग्रामिंग भाषा / मंच / रूपरेखा आदि में निपुणता के लिए प्रयास करने वाले लोगों के साथ पाया है और प्रतीत होता है कि उन्होंने बहुत कम कोडिंग और / या व्यावहारिक किया है प्रयास, लेकिन हर किताब पढ़ी है जिस पर आप एक छड़ी हिला सकते हैं।
डेसलेट प्लैनेट

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

1

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

उदाहरण: जावास्क्रिप्ट की घटना प्रणाली अक्सर हाथ में काम करने के लिए अपर्याप्त है। क्या आप कभी खुद को घटनाओं की धाराओं को संयोजित या रूपांतरित करने में सक्षम नहीं पाते हैं? या घटनाओं की वह श्रृंखला अपने आप में प्रथम श्रेणी के मूल्य थे? आपको मध्यस्थ और / या पर्यवेक्षक पैटर्न की आवश्यकता है। 2-वे डेटा बाइंडिंग की आवश्यकता है? वही कहानी।

भंगुर प्रोटोटाइप पदानुक्रम gotcha नीचे? मिक्सिन / ट्रैक्ट / सबक्लास फैक्टरी पैटर्न बचाव के लिए।


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

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

1
डिजाइन पैटर्न बहुत व्यापक हो सकते हैं। अक्सर व्यापक डिजाइन पैटर्न इतने स्पष्ट होते हैं कि हम उन्हें डिजाइन पैटर्न के रूप में भी नहीं सोचते हैं (विशेषकर जब उनके पास विशेष भाषा समर्थन होता है)। लूप एक डिज़ाइन पैटर्न है। फ़ंक्शंस एक डिज़ाइन पैटर्न हैं। ऑब्जेक्ट एक डिज़ाइन पैटर्न हैं।
Servy

@ अगर यह है कि आपके शब्द का उपयोग कैसे किया जाता है, तो मैं असहमत नहीं हूं, लेकिन मुझे यह आभास हुआ कि ओपी का विशेष रूप से GOFO पैटर्न है।
जारेड स्मिथ

1
@JaredSmith डिज़ाइन पैटर्न सार नहीं हैं । यहां तक ​​कि अगर आप उन्हें बार-बार ठोस समस्या के लिए लागू करते हैं, तो वे अभी भी पैटर्न हैं । आपको एक सामान्य ऑब्जर्वर क्लास लिखने और उस ऑब्ज़र्वर पैटर्न का उपयोग करने की आवश्यकता नहीं है । रजिस्टर करने और उन्हें सूचित करने के लिए ठोस पर्यवेक्षकों और ठोस तरीकों को लिखना अभी भी पैटर्न का उपयोग कर रहा है। कठिन बात पैटर्न को पहचान रही है। कभी-कभी आप इसके नाम को जाने बिना भी एक पैटर्न का उपयोग कर रहे हैं,
Polygnome

1

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

अतिरिक्त:

  • आपकी पसंद के कुछ सरल OSS प्रोजेक्ट के लिए सहयोग करें

  • जब एक ही समस्या को हल करने के दो तरीके होते हैं, तो हमेशा सरल का चयन करें

  • साइड प्रोजेक्ट्स के साथ कुछ अतिरिक्त अनुभव बनाएं जहां आप सभी प्रकार की अजीब त्रुटि करने के लिए स्वतंत्र हैं, और आप डिजाइन पैटर्न "कठिन तरीका" (टीएम) सीखेंगे

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.