क्या कोई डिज़ाइन पैटर्न है जो पायथन जैसी गतिशील भाषाओं में अनावश्यक हैं?


98

मैंने GoF द्वारा डिज़ाइन पैटर्न बुक पढ़ना शुरू कर दिया है। कुछ पैटर्न केवल मामूली वैचारिक मतभेदों के समान हैं।

क्या आपको लगता है कि कई पैटर्न में से कुछ गतिशील भाषा में अनावश्यक हैं जैसे कि पायथन (जैसे कि उन्हें एक गतिशील सुविधा द्वारा प्रतिस्थापित किया जाता है)?


1
एक दिलचस्प सवाल की तरह, इसका मतलब यह है कि भाषा विकल्प प्रभावी रूप से कोड निर्माण के लिए स्थानापन्न कर सकते हैं।
joshin4colours

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

बहुत ही रोचक सवाल। काश मैं +1 के बजाय +5 कर पाता।
मैथअटैक

1
पर नज़र डालें भी है क्या डिजाइन पैटर्न गुम भाषा विशेषताएं और डिजाइन पैटर्न लापता हैं भाषा की सुविधाएँ c2 पर अधिक। इसका एक 'गतिशील भाषा' मुद्दा भी नहीं है। सबसे सरल उदाहरण इटरेटर पैटर्न है जो अजगर, पर्ल (और यहां तक ​​कि जावा - गतिशील नहीं) में तुच्छ है।

जवाबों:


92

पीटर नॉरविग दर्शाता है कि GOF पुस्तक में पाए गए 23 में से 16 डिज़ाइन पैटर्न गतिशील भाषाओं में अदृश्य या सरल हैं (वह लिस्प और डायलन पर केंद्रित है)।

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

मैं पायथन में सबसे सामान्य डिजाइन पैटर्न के कार्यान्वयन (अन्य लोगों द्वारा) के साथ एक गीथॉब भंडार भी रखता हूं ।


महान! यह उत्तर पर एक जगह होगी :) काश हर कोई इस प्रश्न को स्पष्ट रूप से समझ लेता।
जेरेनुक

2
नॉरविग के अनुसार, 16 में से 2 (इंटरप्रेटर और इटरेटर) मैक्रोज़ के कारण "या तो अदृश्य या सरल" हैं (जो पायथन के पास नहीं है)।
mjs

1
यह मेरे लिए स्पष्ट नहीं है कि इन सभी पैटर्नों की आवश्यकता नहीं है क्योंकि लिस्प गतिशील है, बल्कि अन्य विशेषताओं के कारण है जैसे कि एक मजबूत कार्यात्मक भाषा
jk।

@ एमजे इटरेटर पायथन की एक निर्मित विशेषता है।
साकिन

1
यह महान जवाब भी थोड़ा कुछ हद तक व्यर्थ लिंक कैप्शन बदलकर सुधार किया जा सकता को दर्शाता है , प्रस्तुति और भंडार - वे कहीं बेहतर तो कर रहे हैं यहाँ , लेकिन, तुम्हें पता है ... :-)
वुल्फ

59

कोई डिज़ाइन पैटर्न आवश्यक नहीं है। किसी भी भाषा में।

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

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

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

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

इसलिए सभी पैटर्न को अवधारणाओं के रूप में जानें । और विशिष्ट कार्यान्वयन को भूल जाओ। कार्यान्वयन भिन्न होता है, और वास्तविक दुनिया में, यहां तक ​​कि जावा में भी भिन्न होना चाहिए।


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

2
Btw आगंतुक पूरी तरह से उच्च आदेश कार्यों द्वारा प्रतिस्थापित नहीं किया जाता है - यह एक भाषा में दोहरे प्रेषण को लागू करने का एक समाधान है जो मूल रूप से इसका समर्थन नहीं करता है (जैसे कि C # और C ++)। (और यह वास्तव में बहुत संयम से इस्तेमाल किया जाना चाहिए - मैं इसे सबसे अधिक आर्कषक और महंगे पैटर्न में से एक मानता हूं, जिसका उपयोग IMHO है इसलिए इसका औचित्य साबित करना मुश्किल है कि मैंने खुद को अब तक कभी इस्तेमाल नहीं किया है।)
पेटर टॉरक

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

3
@ गेरेनुक: हां, लेकिन मुद्दा यह है कि पैटर्न भाषा-विशिष्ट नहीं हैं, वे आपके सिर के लिए हैं। आप अक्सर पाते हैं कि कुछ पैटर्न को बहुत आसानी से महसूस किया जाता है और अजगर में विभिन्न उपकरणों का उपयोग किया जाता है, लेकिन एक ही अवधारणा आमतौर पर मौजूद है।
जान हुदेक

4
@ PéterTörök: आगंतुक को किसी चीज़ से प्रतिस्थापित नहीं किया जाता है। मुद्दा यह है कि एक ही अवधारणा को विभिन्न मामलों में विभिन्न उपकरणों का उपयोग करके लागू किया जा सकता है, लेकिन मैं अभी भी इसे एक ही पैटर्न मानता हूं।
जान हुदेक

13

सार फैक्ट्री पैटर्न डक-टाइप की गई भाषा जैसे पायथन में अनावश्यक है, क्योंकि यह व्यावहारिक रूप से भाषा में बनाया गया है।


10
खैर, आप अभी भी विभिन्न कारखानों की जरूरत है। आपको बस इंटरफ़ेस परिभाषा की आवश्यकता नहीं है।
स्टेफानो बोरीनी

1
यदि आपके पास एक वर्ग है, तो आपके पास पहले से ही एक कारखाना है। कक्षाएं प्रथम श्रेणी की वस्तुएं हैं और इन्हें हर जगह पास किया जा सकता है और बस एक ऑब्जेक्ट (जावा के विपरीत) बनाने के लिए कहा जाता है। आपको कुछ और बनाने की आवश्यकता नहीं है। यदि आप ऐसा कुछ चाहते हैं जो डिफ़ॉल्ट कंस्ट्रक्टर नहीं है, तो बस किसी प्रकार का एक लंबो / कॉल करने योग्य बनाएं जो कंस्ट्रक्टर को किसी तरह से लपेटता है।
spookylukey

13

केवल एक ही दिमाग में आता है सिंगलटन पैटर्न।

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

ज्यादातर, अजगर में सिंगलेट्स को एक मॉड्यूल के साथ बदल दिया जाता है। अजगर में मॉड्यूल उनके बहुत ही प्रकृति वाले सिंगलटन द्वारा होते हैं; अजगर दुभाषिया इन्हें एक बार और केवल एक बार बनाता है।

डिज़ाइन पैटर में अन्य सभी पैटर्न मैंने पायथन में एक या दूसरे समय में उपयोग किए हैं, और आप पायथन मानक पुस्तकालय और पायथन में ही उनमें से उदाहरण पाएंगे।


2
क्या वास्तव में इन दिनों एक विरोधी पैटर्न नहीं है?
डेन

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

1
और पायथन में हमने कभी भी इससे परेशान नहीं किया क्योंकि हल करने के लिए कभी कोई समस्या नहीं थी।
मार्टीजन पीटरर्स

1
"पायथन आपको हर चीज के लिए वस्तुओं का उपयोग करने के लिए मजबूर नहीं करता है" सच नहीं है। यह सिर्फ जावा की तरह अप्रिय नहीं है, लेकिन फिर भी, पायथन में सब कुछ एक वस्तु है। यहां तक ​​कि मॉड्यूल भी एक वस्तु है।
वारटेक

3
@ डार्थफेट: मैं अच्छी तरह से जानता हूं कि कैसे lenकाम करता है; गुइडो ने यहां एक स्पष्ट विकल्प बनाया । मेरा कहना यह है कि पायथन एक शुद्ध ओओपी भाषा नहीं है; यह एक व्यावहारिक भाषा है। मैं इसे उस तरह चाहता हूं।
मार्टिगन पीटरर्स

8

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

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

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


यह निश्चित रूप से दिलचस्प है। तो विशेष रूप से कौन से पैटर्न का मतलब है कि आप के बारे में भूल सकते हैं, क्योंकि पायथन में बेहतर तरीके हैं?
जेरेनुक

4

मूल "डिज़ाइन पैटर्न" पुस्तक ने कुछ सामान्य मुहावरों को सी + ++ और स्मॉलटाक जैसी अनिवार्य, वस्तु-उन्मुख भाषाओं में उपयोगी और नामांकित किया। लेकिन स्मालटाक एक गतिशील रूप से टाइप की जाने वाली भाषा है, इसलिए यह कड़ाई से गतिशील होने का मामला नहीं हो सकता है।

हालांकि, आपके प्रश्न का उत्तर अभी भी "हाँ" है: इनमें से कुछ डिज़ाइन पैटर्न आधुनिक गतिशील रूप से टाइप की गई भाषाओं के लिए अप्रासंगिक होंगे। अधिक सामान्यतः, विभिन्न भाषाओं में अलग- अलग डिज़ाइन पैटर्न होंगे, विशेषकर विभिन्न प्रकार की भाषाओं में।

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

तो, आप अन्य सुविधाओं की तलाश कर सकते हैं जो आधुनिक गतिशील भाषाओं (या लिस्प जैसे प्राचीन) को अधिक शक्तिशाली बनाते हैं, इनमें से कुछ क्लासिक डिजाइन पैटर्न अप्रासंगिक हैं।


1

डिजाइन पैटर्न विशेष समस्याओं को हल करने के तरीके हैं। यदि कोई समस्या पूरी नहीं होती है, तो इसे हल करने के पैटर्न का कोई फायदा नहीं है।

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

शायद पायथन के अपने डिजाइन पैटर्न जावा और .NET लोगों (इन भाषाओं की प्रकृति के कारण) के लिए उपलब्ध नहीं हैं?


1

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

इसलिए इसमें कोई संदेह नहीं है कि कुछ पैटर्न "जैसा है" लागू नहीं होगा, कुछ का कोई मतलब नहीं हो सकता है और कुछ पैटर्न हैं जो केवल पायथन के लिए सार्थक हो सकते हैं।

अपने प्रश्न पर बिल्कुल वापस आने के लिए: पैटर्न केवल आवश्यक हैं यदि आपको उनकी आवश्यकता है। यदि आपको उनकी कोई आवश्यकता नहीं है (जैसा कि जन हडेक पहले ही कह चुका है) आपको उनका उपयोग नहीं करना है।

इसके अलावा, गोफ में उल्लिखित की तुलना में बहुत अधिक पैटर्न हैं। विकिपीडिया अन्य पैटर्न में देखें

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