प्रोग्रामिंग में डिजाइन पैटर्न कितने महत्वपूर्ण हैं?

Question

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

उनका उद्देश्य क्या है और क्या वे सीखना महत्वपूर्ण हैं?

Comments

वे नौकरी के लिए साक्षात्कार के लिए अच्छे हैं!

— विम

एक डिज़ाइन पैटर्न समस्याओं का समाधान करने के लिए सिर्फ एक नाम है, आमतौर पर आवर्ती तरीका है। आमतौर पर वे भाषाओं की कमियों से पैदा होते हैं।

— जॉन पुरडी

डिजाइन पैटर्न के उद्देश्य को समझने के लिए उन समस्याओं को समझना आवश्यक है जो वे हल करते हैं। इन समस्याओं को समझने के लिए इसे कठिन तरीके से करने के अनुभव की आवश्यकता है :)

— मटकावे

Answer 1

डिजाइन पैटर्न बहुत जल्दी आपके इरादे को संप्रेषित करने के लिए महान हैं- हर कोई जानता है कि एक कारखाना क्या है।

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

Comments

तो आप सभी पैटर्न के लिए हैं, लेकिन वे वास्तव में आपके कोड के लिए नहीं हैं। हां, वे विचार संवाद करने के लिए अच्छे हैं, लेकिन वे तब और बेहतर होते हैं जब आप वास्तविक कोड में पैटर्न देख सकते हैं।

— न्यूटोपियन

वोटों में कमी क्यों? यह वास्तव में सबसे अच्छा जवाब IMHO है। कोडिंग सामान्य ज्ञान है, और कभी-कभी आप जल्दी से एक पैटर्न का उपयोग कर सकते हैं जो समस्या को हल करने के लिए एक अच्छा फिट है। लेकिन एक बार जब लोग उन्हें हर जगह गाली देना शुरू कर देते हैं, तो यह गड़बड़ के एक नरक में बदल जाता है।

— कोडर

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

— ओलिवियर जैकोट-डेसकोम्बर्स 15

यदि यह एक और उद्देश्य प्रदान करता है, तो यह एक और वर्ग होना चाहिए ... चिंताओं का पृथक्करण।

— रात्रि

@ नैट: एक उद्देश्य कई पैटर्न हो सकता है। कोई कारण नहीं है कि एक वर्ग में केवल एक पैटर्न शामिल होना चाहिए। पैटर्न "परमाणु" जिम्मेदारियां नहीं हैं। एक एकल जिम्मेदारी के लिए कई पैटर्न की आवश्यकता हो सकती है।

— डेडएमजी

Answer 2

डिजाइन पैटर्न पर विकिपीडिया लेख से :

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

बहुत लंबे समय से हमारे पास सॉफ्टवेयर इंजीनियरिंग में एक गंभीर समस्या है: आप एक नवागंतुक को एक परियोजना के लिए किराए पर लेते हैं, और कोई फर्क नहीं पड़ता कि वे प्रोग्रामिंग भाषा को कितनी अच्छी तरह से जानते हैं, यह उन चीजों के साथ अद्यतित होने में महीनों का समय लेता है, जो आपके काम की हैं। परियोजना से पहले वे उत्पादक हो सकते हैं। हार्डवेयर इंजीनियरिंग में, उन्होंने इस समस्या को बहुत पहले हल किया था: उनके पास एक सामान्य शब्दावली है जिसे 'योजनाबद्ध चित्र' कहा जाता है। आप एक हार्डवेयर इंजीनियर को किराए पर लेते हैं, उन्हें सुबह अपने हार्डवेयर प्रोजेक्ट की योजनाएँ देते हैं, उनका अध्ययन करते हैं, और शाम होने से पहले एक दिन यह कॉल करने का समय है कि वे सोल्डरिंग बंदूक उठा सकते हैं और उत्पादक बन सकते हैं। हम उस पर बेहतर बनने के तरीकों के साथ आने की कोशिश कर रहे हैं; प्रोग्रामिंग भाषाओं का मानकीकरण एक तरीका था; मानक पुस्तकालय (आजकल कक्षा पुस्तकालय) एक और तरीका है; लेकिन सबसे महत्वपूर्ण तरीकों में से एक शायद डिजाइन पैटर्न रहा है। तो, क्या वे महत्वपूर्ण हैं? बिलकुल!

Comments

इलेक्ट्रिकल इंजीनियरिंग के लिए सॉफ्टवेयर विकास की तुलना करना साइकिल के साथ शनि रॉकेट की तुलना करने के बारे में सटीक है। परिवहन के दोनों तरीके (बिंदु ए से बिंदु बी तक) लेकिन इसके बारे में पूरी तरह से अलग, और गैर-संगत तरीके से चलते हैं।

— jer

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

— माइक नाकिस

@Mike: वहाँ है एक मौलिक अंतर: बिजली के सर्किट कठिन शारीरिक सीमा का बंधन कर रहे हैं। सॉफ्टवेयर सिस्टम मानव बुद्धि की अस्पष्ट सीमाओं से विवश हैं।

— केविन क्लाइन

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

— माइक नाकिस

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

— ९

Answer 3

पैटर्न के अस्तित्व के लिए वास्तव में दो अलग-अलग, पर्याप्त कारण हैं।

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

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

ये लाभ वास्तव में एक दूसरे को सुदृढ़ करते हैं। वे आपको समस्या के कुछ सामान्य वर्गों को जल्दी से हल करने की अनुमति देते हैं, और फिर जब आप कर रहे होते हैं, तो आप बहुत जल्दी संवाद कर सकते हैं कि आपने समस्या को कैसे हल किया।

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

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

Comments

यह गलत धारणा है कि डिजाइन पैटर्न शेल्फ समाधान से दूर हैं। वे "पैटर्न" हैं यह हमेशा कोड में अनुवाद नहीं करता है।

— मार्टिन यॉर्क

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

— मर्फ़

Answer 4

पैटर्न विचारों और अवधारणाओं के पुन: उपयोग और उसी के संचार के लिए एक समान / सुसंगत मंच की स्थापना के बारे में हैं।

हम सभी सहमत हैं (!) है कि सिद्धांत रूप में कोड-पुन: उपयोग एक अच्छी बात है - लेकिन यह कठिन हो जाता है कि हम व्यावहारिक रूप से ऐसा करना चाहते हैं (कुछ मामलों में यह बदल रहा है, लेकिन यह हमेशा एक चुनौती होगी )। लेकिन वास्तव में हम जिस चीज का पुन: उपयोग करना चाहते हैं, वह चीजों को करने का एक तरीका है, किसी विशेष समस्या के समाधान के लिए एक प्रकार के टेम्पलेट का उपयोग करना - ये पैटर्न हैं। तो आप एक ऐसे मामले से रूबरू होते हैं, जहाँ आप कहते हैं कि समस्या X को हल करने के लिए एक अच्छा तरीका पैटर्न Y का उपयोग करना है और हम जानते हैं कि पैटर्न Y के तत्व a, b और c हैं और हम चलते हैं। क्योंकि पैटर्न व्यापक रूप से समझा जाता है कि आपको गहराई से समझाने की ज़रूरत नहीं है जो संचार लाभ है।

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

Answer 5

डिज़ाइन पैटर्न केवल ज्ञात ईंटें हैं जिन पर कोई सॉफ़्टवेयर समाधान बनाया गया है। वे निम्नलिखित कारणों से महत्वपूर्ण हैं:

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

जो ग्रेगोरियो ने पायथन में डिजाइन पैटर्न की कमी के बारे में एक महान बात की

Comments

पायथन में डिजाइन पैटर्न की कमी के बारे में लिंक के लिए धन्यवाद। संपादित करें: उफ़ !! उस स्थान से वीडियो को हटा दिया गया है !! :(

— सौरभ पाटिल

Answer 9

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