सही डिज़ाइन पैटर्न चुनना


32

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

उदाहरण के लिए:

यदि ऑब्जेक्ट संबंधित हैं, लेकिन हम ठोस वर्ग को निर्दिष्ट नहीं करना चाहते हैं, तो सार पर विचार करें

जब तात्कालिकता व्युत्पन्न वर्गों के लिए छोड़ दी जाती है, तो फैक्टरी पर विचार करें

क्रमिक रूप से एक समग्र वस्तु के तत्वों का उपयोग करने की आवश्यकता है, Iterator का प्रयास करें

या ऐसा ही कुछ?


8
आपको क्या लगता है कि महत्व क्या है? programmers.stackexchange.com/questions/70877/…
pdr

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

मैं @pdr से सहमत हूं। मुझे लगता है कि मुझे क्या करने की आवश्यकता है, और पैटर्न के नाम को याद रखने से मुझे कक्षा का नाम रखने में मदद मिलती है ताकि दूसरों को पता चले कि यह क्या करता है।
एमी ब्लेंकशिप

4
वास्तव में। यह केवल "आप सही डिजाइन कैसे चुनते हैं?" सबसे पहले, कोई सही डिज़ाइन नहीं है, बस बहुत सारे गलत हैं। इसके अलावा, यह बवासीर के अनुभव (गलत लोगों को चुनना) के साथ आता है।
तेलस्टिन

जवाबों:


109

आज की कोडिंग दुनिया में एक महत्वपूर्ण गलत धारणा यह है कि पैटर्न ब्लॉक का निर्माण कर रहे हैं। आप AbstractFactoryयहां और Flyweightवहां और शायद Singletonवहां पर ले जाते हैं और उन्हें एक्सएमएल और प्रीस्टो के साथ जोड़ते हैं, आपको एक काम करने वाला एप्लिकेशन मिला है।

वे नहीं हैं।

हम्म, यह काफी बड़ा नहीं था।

पैटर्न ब्लॉक का निर्माण नहीं कर रहे हैं

वह बेहतर है।

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

लेकिन ध्यान दें, यह कुछ ऐसा है जिसे आप अपने कोड में खोजते हैं , न कि कुछ जिसके साथ आप शुरू करते हैं। जावा के रचनाकारों ने कहा "ओह, हम शुरू में एक फ्लाईवेट को इंटेगर में डाल देंगे", लेकिन एक प्रदर्शन समस्या का एहसास हुआ जिसे फ्लाईवेट द्वारा हल किया जा सकता है

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

पैटर्न के साथ शुरू करना एक समाधान होने और समस्या की तलाश करने जैसा है। यह एक बुरी बात है: यह इंजीनियरिंग और डिजाइन में अंततः अनम्यता की ओर जाता है।

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

एरिक गामा ( गामा, हेल्म, जॉनसन, और विसीड्स ) के साथ एक साक्षात्कार का एक अंश यहां दिया गया है : डिजाइन पैटर्न का उपयोग कैसे करें :

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


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

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

इसलिए उन सभी को सूचीबद्ध करने का कोई भी प्रयास स्वाभाविक रूप से अधूरा है। आप एक खोज करते हैं, यह पता लगाते हैं कि इसका उपयोग कैसे करना है और फिर यह अंततः दूसरी प्रकृति बन जाती है और आपको यह सोचने की आवश्यकता नहीं है कि इसे कैसे या कब फिर से उपयोग करना है (जब तक कोई आपसे इसे समझाने के लिए नहीं कहता है)।


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

1
मैं हमेशा डिजाइन सिद्धांतों के साथ खुद को परिचित करने के लिए पैटर्न को देखने के लिए शुरू करने वाले डेवलपर्स की सलाह देता हूं। हर पैटर्न डिजाइन के कुछ सिद्धांतों का एक उदाहरण है (सिद्धांतों का 'ठोस' सेट सिर्फ एक उदाहरण है)।
ryscl

2
शायद आप एक डेकोरेटर और मुखौटा जोड़ते हैं, आपके पास एक ऐप होगा ;-) एक और तरीका, डिज़ाइन पैटर्न का बिंदु हमें एक नाम देना है, एक आम भाषा जब हम चर्चा कर रहे हैं कि हम क्या बना रहे हैं। यह मुश्किल से जीता विकास ज्ञान के ढेर के लिए आशुलिपि है।
एबर्ड

2
यहाँ लाइनों के बीच पढ़ना, एक डिज़ाइन पैटर्न चुनने के चरण: 1. हमेशा किसी भी कोड के बारे में सोचें जो आप काम कर रहे हैं। 2. विशिष्ट कोड को आधार समस्या में रखें 3. क्या उस समस्या का कोई ज्ञात समाधान है (डिज़ाइन पैटर्न )? 4. हां, मैं उस समाधान को अपनी बारीकियों पर कैसे लागू करूं? 5. अपनी विशिष्ट समस्या का समाधान बनाने के लिए, अमूर्त समस्या के सामान्य समाधान को अपनाएं।
क्रिस

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

18

मैंने खुद से पूछा:

  1. मैं किस समस्या को हल करने की कोशिश कर रहा हूं?
  2. कौन सा सॉफ़्टवेयर डिज़ाइन पैटर्न (यदि कोई हो) सबसे अधिक समान समस्या को हल करता है, या मेरी समस्या को हल करने की दिशा में एक तार्किक मार्ग प्रदान करता है?
  3. क्या मुझे अतिरिक्त अमूर्त (और जटिलता) की आवश्यकता है जो पैटर्न प्रदान करता है, या क्या यह मेरी विशेष समस्या के लिए अति-इंजीनियरिंग है? क्या पैटर्न के बिना समस्या को अधिक सरल, अधिक कुशल तरीके से हल किया जा सकता है?

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


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

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