डिज़ाइन पैटर्न: क्या मुझे उन्हें सीखना चाहिए? [बन्द है]


13

इसलिए यह अजीब है कि दो सवालों को बैक-टू-बैक पूछ रहा हूं, लेकिन वे बहुत संबंधित नहीं हैं और मैं उन्हें गठबंधन नहीं करना चाहता था, लेकिन मैं सवालों का जवाब नहीं दे रहा हूं, मैं वादा करता हूं!

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

एक बार फिर धन्यवाद!


क्या आपने [डिज़ाइन-पैटर्न] के रूप में टैग किए गए अन्य प्रश्नों को पढ़ा है?
पीटर टेलर

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

1
मैं इसे एक सटीक पोस्ट है नहीं लगता है, लेकिन मुझे आश्चर्य है कि तुम क्या जरूरत है जो जैसे के जवाब द्वारा आपूर्ति नहीं कर रहा है programmers.stackexchange.com/questions/84098/... programmers.stackexchange.com/questions/78825/...
पीटर टेलर

कम से कम किसी ने इसे कॉलेज में संदर्भित किया था। मैंने इसके बारे में तब तक नहीं सुना, जब तक कि मैंने अपनी दूसरी पोस्ट-कॉलेज की नौकरी के लिए साक्षात्कार शुरू नहीं किया (जहाँ जाहिरा तौर पर मैं उपयुक्त नहीं था क्योंकि मैंने सिंगलटन के बारे में नहीं सुना था।
मेयो

यह दिलचस्प हो सकता है: mahemoff.com/paper/software/learningGoFPatterns
टॉम एंडरसन

जवाबों:


12

हमेशा की तरह

निर्भर करता है

यह इस बात पर निर्भर करता है कि आपने कितना OOP किया है कि क्या आप डिजाइन पैटर्न का उपयोग कर पाएंगे या पहचान पाएंगे

यह इस बात पर निर्भर करता है कि आप कितने अनुशासित हैं कि क्या आप एक बार सीखे गए पैटर्न को सही ढंग से लागू कर पाएंगे, और न कि पागल की तरह लौकिक आदमी की तरह पागल हो जाएंगे

दूसरी ओर ... पाँच उंगलियाँ!

यदि आपने OOP के कुछ वर्षों में गंभीर काम किया है या आपके पास रेल पर रखने के लिए एक विश्वसनीय संरक्षक है या आप OOP-nerd पढ़ना पसंद करते हैं, तो हर तरह से पुस्तक खरीदें और उसका अध्ययन करें।

यह पैटर्न को जानने में मदद करता है ताकि आप पहचान सकें कि उनका उपयोग कब करना है, और कब उनका उपयोग नहीं करना है।


मुझे इतना ज्यादा लगा। जिज्ञासा से बाहर, अगर आपको कुछ चुनना था कि आप सबसे महत्वपूर्ण वैचारिक रूप से, या सबसे लोकप्रिय पर विचार करेंगे, तो वे क्या होंगे?
5

1
@prelic: सिंगलटन - इसके आसपास के विवाद के कारण - और आगंतुक - क्योंकि यह बहुत उपयोगी है
स्टीवन ए। लोव

2
@ व्याख्या: मैं रणनीति और पर्यवेक्षक के साथ शुरू करूंगा - क्योंकि वे बहुत उपयोगी हैं
फाल्कन

1
इस विषय पर +1 सर्वश्रेष्ठ टिप्पणी! पैटर्न मैं नियमित रूप से उपयोग करते हैं: कमांड, एडेप्टर और फैक्टरी विधि।
ओलिवर वीलर

सांस लेने की तरह मैं का उपयोग कर रहे हैं सिंगलटन, टेम्पलेट विधि, डेकोरेटर, और समग्र। और Iterator, लेकिन लगभग हमेशा की आड़ में java.util.Iterator, जहां यह शायद ही एक पैटर्न की तरह लगता है। रणनीति, आगंतुक, और मुखौटा मैं होशपूर्वक लागू होगा जब मैं उनके लिए जरूरत देखते हैं।
टॉम एंडरसन

21

हां, आपको उन्हें सीखना चाहिए।

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

महान पैटर्न के बहुमत बहुत ही उपयोगी और आम है । अन्य लोग उतने लोकप्रिय नहीं हो सकते हैं, लेकिन अभी भी कुछ संकीर्ण उपयोग हैं जहां वे बिल्कुल फिट हैं।

एक और कारण है कि यह पढ़ने लायक क्यों है: यह आपको सिखाएगा कि कैसे सोचना है । यकीन है, यह एक चांदी की गोली नहीं है, लेकिन अभी भी एक अमूल्य प्रेरणा है।

अंतिम लेकिन कम से कम, कभी नहीं, कभी भी, किसी भी परिस्थिति में कोशिश करें और समस्या को एक पैटर्न या उपकरण के रूप में फिट करें । यह बहुत ही बुरी और खतरनाक सोच है! समझें कि उपकरण कैसे काम करता है और समस्या से निपटने के लिए बुद्धिमानी से इसका उपयोग करता है, कभी दूसरे तरीके से नहीं।

अधिक उपकरण आप अच्छी तरह से जानते हैं, बेहतर है। कभी-कभी एक उपकरण आपकी सोच को प्रेरित कर सकता है (बजाय सीधे एक समस्या को हल करने के), एक महान समाधान के लिए उनमें से कुछ को आप जोड़ देंगे।

GOF पुस्तक कई उपयोगी उपकरणों का एक बड़ा स्रोत है जो हम दैनिक उपयोग करते हैं


अच्छी सलाह के लिए धन्यवाद! मेरी इच्छा है कि मैं
चेक

6

डिज़ाइन पैटर्स के बारे में बस थोड़ा सा जानने से सबसे महत्वपूर्ण लाभ यह है कि आप जानते हैं कि शब्दों का क्या अर्थ है। दूसरे शब्दों में आप सामान्य शब्दावली जानते हैं ।

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

उदाहरण आगंतुक, सिंगलटन और सज्जाकार हैं।

इसलिए दूसरे शब्दों में, मेरा सुझाव है कि आप कम से कम नामों से परिचित हों और वे क्या करते हैं।


5

हाँ, लेकिन सतर्क के साथ!

हाँ भाग:

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

सतर्क भाग के साथ:

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

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


1

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

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

इसके अलावा, बहुत से लोग पैटर्न को देखते हैं और कहते हैं, "ओह, मैंने अभी हल किया है कि .... मैंने कोई मूर्खतापूर्ण पैटर्न का उपयोग नहीं किया।" बात यह है कि "...." लगभग अनिवार्य रूप से एक दिए गए पैटर्न समाधान के एएन कार्यान्वयन का वर्णन करता है। उदाहरण के लिए, फ़ंक्शन पॉइंटर्स की एक सरणी एक ज़िम्मेदारी की श्रृंखला के रूप में कार्य कर सकती है, भले ही यह पारंपरिक नुस्खा की तरह न हो।

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

हाँ, संक्षेप में, सीखने के पैटर्न न केवल इसके लायक हैं ... आप उन्हें न सीखकर खुद को सीमित करते हैं। जब मैं कहता हूं, मुझे सभी प्रेरक सिद्धांतों और समाधान के सामान्य आकार का वर्णन नहीं करना है, "मुझे एक आगंतुक की तरह लगता है।"

यहाँ उनकी वेबसाइट है: http://www.netobjectives.com/PatternRepository/index.php?title=Main/Page


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

1

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

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

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


0

डिजाइन पैटर्न desing की समस्याओं को हल करने की कोशिश करते हैं।

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

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


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

0

मैं कई अन्य उत्तरों में किए गए बिंदुओं से सहमत हूं कि कैसे छोटे अनुभव के साथ डिजाइन पैटर्न लागू करना खतरनाक हो सकता है।

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


0

मेरा सवाल यह है कि क्या यह गोफ बुक में पैटर्न सीखने लायक है?

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

क्या वे पर्याप्त दिखाते हैं कि मुझे उन्हें सीखना चाहिए?

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

एक क्लासिक पैटर्न को फिट करने और समस्या को हल करने के लिए यह हमेशा काउंटर-सहज लगता था

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

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