क्या गैंग ऑफ़ फोर ने अच्छी तरह से "पैटर्न स्पेस" का पता लगाया?


144

जब से मैंने पहली बार गैंग ऑफ़ फोर (GoF) डिज़ाइन पैटर्न के बारे में सीखा , कम से कम 10 साल पहले, मुझे यह आभास हो रहा है कि ये 23 पैटर्न केवल कुछ बड़े का एक छोटा सा नमूना होना चाहिए जिसे मैं पैटर्न स्पेस कहलाना पसंद करता हूँ । इस काल्पनिक पैटर्न स्पेस में सामान्य वस्तु उन्मुख सॉफ़्टवेयर डिज़ाइन समस्याओं के लिए सभी अनुशंसित समाधान (ज्ञात या अज्ञात) शामिल हैं।

इसलिए मुझे ज्ञात और प्रलेखित डिज़ाइन पैटर्न की संख्या में काफी वृद्धि होने की उम्मीद थी।

ऐसा नहीं हुआ। गोफ पुस्तक के बाहर आने के 20 से अधिक वर्षों के बाद, विकिपीडिया लेख में केवल 12 अतिरिक्त पैटर्न सूचीबद्ध हैं, जिनमें से अधिकांश मूल लोगों की तुलना में बहुत कम लोकप्रिय हैं। (मैंने समवर्ती पैटर्न को यहां शामिल नहीं किया क्योंकि वे एक विशिष्ट विषय को कवर करते हैं।)

कारण क्या हैं?

  • क्या मेरे विचार से पैटर्न का GoF वास्तव में अधिक व्यापक है?

  • क्या नए पैटर्न को खोजने में दिलचस्पी थी, हो सकता है कि क्योंकि वे सॉफ्टवेयर डिजाइन में सभी उपयोगी नहीं पाए गए हैं?

  • कुछ और?


49
पैटर्न हर जगह हैं, लेकिन वे अक्सर बेस्वाद और रोबोट तरीके से उपयोग किए जाते हैं। उस कारण से, मुझे लगता है, पैटर्न कैटलॉग विचार कम लोकप्रिय हो गया।
usr

6
डिजाइन अंतरिक्ष? किसी ने मार्क रोसवाटर को यहाँ नीचे लाया, स्टेट!
corsiKa

16
मार्टिन फॉवलर ने 2003 में एंटरप्राइज एप्लिकेशन आर्किटेक्चर के पैटर्न को 50 पैटर्न के बारे में प्रलेखित किया, जिनमें से कई आज भी काफी पुनर्गठन योग्य और अच्छी तरह से उपयोग किए जाते हैं, जैसे "डेटा मैपर", "प्लगिन", "लेज़ी लोड", "सर्विस लेयर, आदि।"
ब्रायन रोजर्स

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

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

जवाबों:


165

जब पुस्तक सामने आई, तो बहुत से लोगों ने उस तरह से सोचा, और "पैटर्न लाइब्रेरी" या यहां तक ​​कि "सामान्य समुदाय" बनाने के लिए कई प्रयास किए गए। आप अभी भी उनमें से कुछ पा सकते हैं:

परन्तु फिर...

क्या नए पैटर्न को खोजने में रुचि थी, हो सकता है क्योंकि वे वास्तव में सॉफ्टवेयर डिजाइन में उपयोगी नहीं हैं?

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

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

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


50
विवादास्पद राय: अमूर्त कारखाना वैसे भी एक कोड गंध है :)
मेटा 20

66
विवादास्पद राय, हो सकता है, लेकिन व्यक्त करने के लिए एक ओह इतना महत्वपूर्ण राय। डिज़ाइन पैटर्न से सम्राट के नए कपड़ों का एक उदाहरण बनने का खतरा है, जहां हम सभी यह सवाल करने से डरते हैं कि क्या वे उपयोगी हैं। बहुत बढ़िया।
डेविड अरनो

18
@ मीता फाइटControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
corsiKa

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

11
@ क्रिस मैं आपकी बात नहीं देखता ... जैसा कि मैंने कहा कि GoF ने OO कमियों को दूर करने की कोशिश की, और विशेष रूप से C ++ 98 कमियों के रूप में यह स्मॉलटॉक के साथ-साथ उनकी पसंद की भाषा थी। उन्होंने वास्तव में लिखा: "प्रोग्रामिंग भाषा का चुनाव महत्वपूर्ण है क्योंकि यह किसी के दृष्टिकोण को प्रभावित करता है। हमारे पैटर्न स्मॉलटॉक / सी ++ - स्तरीय भाषा सुविधाओं को मानते हैं, और यह पसंद निर्धारित करती है कि क्या आसानी से लागू नहीं किया जा सकता है।"
शौतीह

108

मुझे यह आभास हो रहा है कि इन २३ प्रतिमानों में केवल कुछ बड़ा का एक छोटा सा नमूना होना चाहिए, जिसे मैं पैटर्न स्पेस कहलाना पसंद करता हूं।

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

डिज़ाइन पैटर्न (GoF अर्थ में) लेकिन एक उद्देश्य है: आप जिस प्रोग्रामिंग भाषा का उपयोग कर रहे हैं उसमें कमियों की भरपाई करना।

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


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

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

12
@ जूल्स: मेरा मानना ​​है कि मूल गोफ बुक सूचीबद्ध इट्रेटर एक पैटर्न के रूप में है, लेकिन अब भाषा की सुविधा में इसका परिवर्तन मूल रूप से हर दूरस्थ ओओपी भाषा में पूरा हो गया है।
केविन

9
@RubberDuck पैटर्न को पहले से लागू करने वाले पैटर्न को अप्रचलित कैसे बना रहा है? यह अभी भी डिजाइन पैटर्न लागू किया जा रहा है। भाषा सुविधाओं के विभिन्न सेट पैटर्न के अलग-अलग कार्यान्वयन को जन्म दे सकते हैं, लेकिन पैटर्न अभी भी वहाँ है। पैटर्न आमतौर पर उपयोग की जाने वाली रणनीतियों को पुनः प्राप्त करने के लिए नाम देकर संचार को आसान बनाने के लिए होते हैं। मामले में, .NET क्लास को कहा जाता है ObservableSomething<T>जो उनके उद्देश्य को समझना आसान बनाता है, क्योंकि यह सामान्यतः ज्ञात पैटर्न नाम का उपयोग करता है। एक पैटर्न एक विचार है, एक सटीक कार्यान्वयन नहीं है।
null

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

61

मुझे लगता है कि तीन कारक हैं जो यहां खेलते हैं।

क्रिटिकल मास की कमी

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

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

इसे थोड़ा और विचित्र रूप से लगाने के लिए: डिज़ाइन पैटर्न विशेष रूप से विफल रहे क्योंकि वे विफल रहे।

बहुत सारे पैटर्न

मुझे लगता है कि दूसरा प्रमुख कारक है, अगर कुछ भी, तो उन्होंने शुरुआत में बहुत सारे पैटर्न का नाम दिया। उचित संख्या में मामलों में, पैटर्न के बीच के अंतर पर्याप्त रूप से सूक्ष्म हैं कि यह वास्तविक निश्चितता के साथ कहना असंभव है कि क्या एक विशेष वर्ग एक पैटर्न या किसी अन्य (या शायद दोनों - या शायद न तो) पर फिट बैठता है।

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

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

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

हत्तोसाहित

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

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

सारांश

डिज़ाइन पैटर्न विफल हुए क्योंकि:

  1. वे महत्वपूर्ण द्रव्यमान प्राप्त करने में विफल रहे।
  2. स्पष्टता की गारंटी के लिए पैटर्न के बीच अंतर अपर्याप्त था।
  3. वे ज्यादातर कोड के हिस्सों से निपटते हैं, लगभग किसी को भी वास्तव में परवाह नहीं है।

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

5
बहुत अच्छा जवाब।
रॉबर्ट हार्वे

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

3
@DavidRicherby: ठीक है, तो चलो उपमा के "निर्माता पक्ष" संस्करण का उपयोग करें। क्या यह मायने रखता है कि जॉन जो गुडइयर के लिए टायर डिजाइन करता है, वह उस प्रकार के खांचे के लिए एक शब्द का उपयोग करता है, लेकिन पियरे जो मिशेलिन के लिए काम करता है, एक पूरी तरह से अलग शब्द का उपयोग करता है? क्या यह मायने रखता है कि कोई शब्द केवल खांचे का जिक्र करता है, लेकिन दूसरा शब्द केंद्र के एक तरफ क्षैतिज खांचे के साथ एक पूर्ण टायर का उल्लेख करता है और दूसरे पर विकर्ण खांचे?
जेरी कॉफिन

2
@ मिनीबिस: मैं ज्यादातर हाँ कहूँगा, वे विफल रहे हैं। मैं कहूंगा कि अधिकांश प्रोग्रामर पहचानने वाले आधा दर्जन से कम पैटर्न हैं। सिंगलटन सर्वविदित है, लेकिन वास्तव में केवल शायद ही कभी (सबसे अच्छे रूप में) लागू होता है। नाम "फैक्टरी" लंबे समय से पहले "पैटर्न" (मैं 1970 के अंत या में इसके उपयोग याद साथ आया था आम उपयोग में था बहुत 1980 के दशक)। पैटर्न एक शब्दावली बनाने वाले थे, लेकिन वर्तमान में वे ग्रीक में मेरी शब्दावली के बारे में हैं - पर्याप्त रूप से (संभवतः) खुद को परेशानी में डालते हैं, लेकिन निश्चित रूप से एक मेनू को ऑर्डर करने के लिए पर्याप्त नहीं है, बहुत कम एक सार्थक बातचीत करते हैं।
जेरी कॉफिन

35

पैटर्न गायब हैं सार, सरल पैटर्न सार हैं, जटिल पैटर्न मान्यता प्राप्त नहीं हैं, इसलिए पैटर्न उपयोगी नहीं हैं (कुछ उच्च स्तर वाले को छोड़कर)।

मुझे लगता है कि पॉल ग्राहम ने इसे सबसे अच्छा कहा:

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

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


2
निजी तौर पर, मैं किसी भी तरह इस विचार को वास्तव में पसंद करता हूं। लेकिन फिर, कोड मनुष्यों और लोगों द्वारा पैटर्न की तरह पठनीय होना चाहिए। पैटर्न हमें अपना रास्ता खोजने में मदद करते हैं। हमारे कोड से सभी पैटर्न को हटाने से यह अपठनीय हो जाएगा।
फ्रैंक पफर

2
@ मुझे लगता है कि जहां पीजी से आ रहा है वह यह है कि एक पैटर्न एक अंतर्निहित फ़ंक्शन की 'गंध' है जिसे आप अमूर्त कर सकते हैं, और यह तथ्य कि आपने इसे फ़ंक्शन या मैक्रो में नहीं निकाला है, जो दोहराव का कारण बन रहा है - जैसे यदि आपके पास कोई String.replaceफ़ंक्शन नहीं है , तो आप इसे एक पैटर्न के रूप में पॉप अप करने की कल्पना कर सकते हैं, लेकिन इसे फिर से लागू करने के लिए जारी रखने के बजाय इसे लिखना बेहतर है। सहमत हैं कि यदि आप इन चीजों को ठीक से नाम नहीं देते हैं, तो इसे पढ़ना कठिन हो जाएगा, लेकिन जब यह सही हो जाता है, तो कोड अधिक घोषित रूप से आईएमओ (उदाहरण के लिए getOrElseविकल्प मोनड्स बनाम अशक्त जाँच की शैली) को
पढ़ता है

11
पॉल ग्राहम का उद्धरण आपके समाधानों को DRY रखने के बारे में था, जो कि GoF "पैटर्न" विचार से अलग है। GoF का विचार आमतौर पर उपयोग किए जाने वाले समाधानों को नाम देने के बारे में था। हम पहले से ही कर रहे थे कि इससे पहले कि GoF ने उनकी किताब प्रकाशित की। उदाहरण के लिए, मैं अपने सह-कार्यकर्ता को बता सकता हूं कि मैं एक कतार का उपयोग करने जा रहा हूं , और मेरा सह-कार्यकर्ता तुरंत जानता है कि मैं क्या बात कर रहा हूं मेरे बारे में बताए बिना कि कतार क्या करती है या कैसे काम करती है। लेकिन, ऊपर माइकल बोर्गवर्ड का उत्कृष्ट उत्तर देखें।
सोलोमन स्लो

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

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

13

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


1
राइट, पैटर्न केवल तभी काम कर सकते हैं जब उनमें से बहुत सारे नहीं हैं। लेकिन GoF वाले अभी भी सबसे लोकप्रिय क्यों हैं? उनमें से कुछ अब कई लोगों (सिंग्लटन, बिल्डर, आदि) द्वारा एंटीपैटर्न के रूप में माना जाता है। यह कुल संख्या में वृद्धि के बिना नए, अधिक उपयोगी पैटर्न के लिए जगह बनाना चाहिए।
फ्रैंक पफर

2
मुझे लगता है कि यह 10 आज्ञाओं की तरह है। स्रोत केवल 2
चार्ट

9
हां, और यह कभी-कभी ऐसा लगता है जैसे आधुनिक सॉफ्टवेयर इंजीनियरिंग GoF से संबंधित है जैसे मध्यकालीन विद्वान अरस्तू से संबंधित है।
फ्रैंक पफर

11

कुछ ऐसा जो अन्य उत्तरों में से किसी का भी उल्लेख नहीं करता है जो प्रासंगिक है:

गतिशील रूप से टाइप की गई भाषाओं का उदय।

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

मूल GoF पुस्तक में स्मालटाक और c ++ दोनों में पैटर्न थे, और यदि स्मृति कार्य करती है तो पैटर्न हमेशा स्मॉलटॉक में छोटे होते थे और कभी-कभी काफी होते थे। क्लासिक डिज़ाइन पैटर्न की कुछ विशेषताएं वास्तव में गतिशील रूप से टाइप किए गए सिस्टम में गतिशील सुविधाओं को जोड़ने के तरीके हैं (जैसे कि पहले से ही चर्चा की गई AbstractFactory, जिसमें आप रनटाइम डेटा के आधार पर सही वर्ग को तुरंत टाइप करते हैं)। अन्य गतिशील भाषाओं में इतने कम हैं कि वे केवल भाषा के मुहावरेदार उपयोग में पिघल जाते हैं।


10

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

तथ्य यह है कि GoF ने वास्तव में 'डिजाइन पैटर्नों का अच्छी तरह से पता लगाने' का प्रयास नहीं किया था। इसके बजाय, वे एक बहुत बड़ी परियोजना पर लगे हुए थे: सीएस में 'पैटर्न लैंग्वेज' को लागू करने के लिए, इसके सभी विचित्र रूप से आर्कान्स ऑफ फोर्सेस, पार्टिसिपेंट्स, आदि के साथ, जो कि बस विफल हो गया, क्योंकि यह बुनियादी रूप से गलत था, साथ ही साथ व्यर्थ भी।

वे क्या था पूरा, जो उपयोगी था, दो बातें था:

  • कई उपयोगी ट्रिक प्रकाशित करें जैसे विज़िटर पैटर्न
  • उन नामों का एक मानक सेट प्रदान करें जो बड़े पैमाने पर अटक गए हैं: फैक्टरी, एडेप्टर, Iterator, ... यदि आप CORBA को देखते हैं, जो पहले से डिज़ाइन किया गया था, तो आपको इसका मूल्य दिखाई देगा: सभी प्रकार के 'विदेशी' नाम जैसे इंटरसेप्टर , नौकर, ब्रोकर, ...

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


क्या यह अभी भी दुःखद है अगर इसका परिणाम इस चर्चा में आया (और वह सब
उलझ गया

1
@ r3wt गैर अनुक्रमिक। जो मैंने कहा वह दुखद है कि आईटी उद्योग की कमजोरी यह सोचने के लिए है कि हर नए विकास के लिए पौराणिक चांदी की गोली चल रही है, और संयोग से अपने स्वयं के कुछ पूर्व कामों के लिए।
user207421

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

6

पीएलओपी ( पैटर्न लैंग्वेज ऑफ प्रोग्राम डिजाइन ) शीर्षक वाली कई पुस्तकें थीं / हैं जो वार्षिक सम्मेलन में प्रस्तुत किए गए कागजात की प्रत्येक रचना हैं ।

पुस्तकों को पढ़ते हुए, मैंने पाया कि कुछ पैटर्न मेरे लिए दिलचस्प और नए थे, उनमें से कुछ मानक (जैसे "आधा ऑब्जेक्ट प्लस प्रोटोकॉल")।

तो नहीं, GoF का संग्रह संपूर्ण नहीं था, और लोगों को नए लोगों को इकट्ठा करने / वर्णन करने / खोजने / खोजने के लिए प्रेरित / प्रेरित करता था।

"केवल 12 अतिरिक्त पैटर्न विकिपीडिया लेख में सूचीबद्ध हैं" संभवत: एक पूर्ण संग्रह भी नहीं हैं: यानी अन्य कहीं भी प्रलेखित हैं, जैसे पीएलओपी पुस्तकों में और शायद कहीं और भी।


हां, यदि आप उन्हें खोजते हैं, तो आप सैकड़ों पैटर्न के विवरण पा सकते हैं। लेकिन इनमें से कोई भी GoF वालों की तरह लोकप्रिय नहीं है।
फ्रैंक पफर

इसका कारण यह था कि जब मुझे प्रकाशित (बाद में) किया गया था तो मैंने गोफ पुस्तक को पढ़ना पसंद किया था।
क्रिस डब्ल्यूडब्ल्यू

1
@FrankPuffer मुझे यकीन है कि पैटर्न लोकप्रिय हैं, भले ही नाम न हों।
dcorking

5

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

आप उम्मीद करते हैं कि एक इलेक्ट्रीशियन के पास कुछ उपकरण हैं जो एक सामान्य बिल्डर नहीं करता है, इसी तरह आप उम्मीद करेंगे कि "निर्भरता गुण" के लिए डिजाइन पैटर्न को जानने के लिए WPF प्रोग्रामर, या "SQL प्रोग्रामर" को ट्रिगर का उपयोग करने के लिए डिज़ाइन पैटर्न जानने के लिए ऑडिट डेटा बनाएँ।

हालाँकि, हम इन्हें केवल एक तकनीक के साथ उपयोग किए जाने के कारण "डिज़ाइन पैटर्न" के रूप में नहीं सोचते हैं।

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


3

यहाँ एरिक गामा के साथ एक साक्षात्कार है जहाँ वह अपने पैटर्न के चयन पर विचार करते हैं और वे आज क्या बदलेंगे (आज से 10 साल पहले, हाहा)।

http://www.informit.com/articles/article.aspx?p=1404056

लैरी: आप "डिज़ाइन पैटर्न" को कैसे परिष्कृत करेंगे?

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

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

तो यहाँ कुछ बदलाव हैं:

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

तुम मुझे क्यों नीचा दिखा रहे हो? कृपया एक टिप्पणी में समझाएं ताकि मैं उत्तर को बेहतर बना सकूं।
अनकुहन

3

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

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


अच्छी बात है, हालाँकि मुझे संदेह है कि बहुत से लोग किताब (या सामान्य रूप से पैटर्न) को समझते हैं।
फ्रैंक पफर

@ lud1977 अगर हम इतिहास को रिकॉर्ड नहीं करते हैं, तो भविष्य को एक ही जाल में गिरने से रोकता है? इस प्रकार, इसे हमेशा दर्ज किया जाना चाहिए। यह व्यर्थ नहीं है।
r3wt

2

इसलिए मुझे ज्ञात और प्रलेखित डिज़ाइन पैटर्न की संख्या में काफी वृद्धि होने की उम्मीद थी।

ऐसा नहीं हुआ। गोफ पुस्तक के बाहर आने के 20 से अधिक वर्षों के बाद, विकिपीडिया लेख में केवल 12 अतिरिक्त पैटर्न सूचीबद्ध हैं, जिनमें से अधिकांश मूल लोगों की तुलना में बहुत कम लोकप्रिय हैं। (मैंने समवर्ती पैटर्न को यहां शामिल नहीं किया क्योंकि वे एक विशिष्ट विषय को कवर करते हैं।)

GoF पुस्तक और विकिपीडिया शायद ही ज्ञात डिज़ाइन पैटर्न का एकमात्र स्रोत हैं। यदि आप Amazon.com में "डिज़ाइन पैटर्न" की खोज करते हैं, तो आपको सैकड़ों किताबें मिलती हैं (इस खोज का प्रयास करें )। मुझे लगता है कि वे केवल विकिपीडिया लेख में सबसे प्रसिद्ध पैटर्न को सूचीबद्ध करते हैं ।

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


-1

संभवतः बहुत सारी संरचनाएँ हैं जिनके बारे में अभी तक सोचा नहीं गया है। जब तक लोग सॉफ्टवेयर विकसित कर रहे हैं, तब तक डिजाइन की चुनौतियां दूर होंगी। उनमें से कुछ अच्छी तरह से चालाक नए पैटर्न का उपयोग कर हल किया जा सकता है कि दूसरों का उपयोग कर सकता है।

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

क्या हमारे पास एक बार अचानक रोबोट बनाने का ज्ञान है जो हमारे पास रोबोट है जो इसे हमारे लिए कर सकता है? मैं बहस नहीं करूँगा, यह नहीं है। यह कम प्रासंगिक है, निश्चित है - और शायद अध्ययन के लिए बहुत कम पुरस्कृत है, क्योंकि मांग में तेजी से गिरावट आई है, और कोई भी इसका अध्ययन नहीं कर रहा है।

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


-2

पैटर्न अनंत हैं .. आप नए पैटर्न बनाने के लिए प्रत्येक पैटर्न को मिला सकते हैं या एन मेल कर सकते हैं .. एंटरप्राइज़ एकीकरण पैटर्न भी अच्छी तरह से परिभाषित हैं..तो हाँ gof ने uml का उपयोग करते हुए दस्तावेज़ों के पैटर्न का दर्द उठाया और उन्हें समझाने के लिए एक मानक बनाया .. लेकिन प्रत्येक डोमेन पैटर्न के लिए विकसित होते हैं और वे अजगर या स्काला जैसी अभिव्यंजक भाषा के लिए भी बदलते हैं।

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