डिजाइन पैटर्न का अध्ययन कैसे करें? [बन्द है]

Question

मैंने डिज़ाइन पैटर्न पर लगभग 4-5 किताबें पढ़ी हैं, लेकिन फिर भी मुझे नहीं लगता कि मैं डिज़ाइन पैटर्न में इंटरमीडिएट स्तर के करीब आया हूं?

मुझे डिज़ाइन पैटर्न का अध्ययन कैसे करना चाहिए?

क्या डिजाइन पैटर्न के लिए कोई अच्छी पुस्तक है?

मुझे पता है कि यह केवल अनुभव के साथ आएगा लेकिन इन पर महारत हासिल करने का कोई रास्ता होना चाहिए?

Comments

डिजाइन पैटर्न सीखने का सबसे अच्छा तरीका एक प्रोजेक्ट करके है। जब आप प्रोजेक्ट में पैटर्न देखते हैं तो आपको पता चलेगा कि उनका उपयोग कब करना है। यह एक लेख है जो एक प्रोजेक्ट कोडप्रोजेक्ट.com

— शिवप्रसाद कोईराला

Antipatterns के साथ ही deviq.com/antipatterns

— डेवलपर

आप इसे यहां से सीख सकते हैं, play.google.com/store/apps/…

— कीउर थुमर

शायद देर से लेकिन अभी भी किसी की मदद कर सकते हैं .. geeksforgeeks.org/software-design-patterns को समझने के लिए मूल बातें और परिदृश्यों को समझाएं जहां उनका उपयोग किया जा सकता है। प्रत्येक पैटर्न की नींव और उद्देश्य को समझने में मेरी मदद की

— zeetit

यह भी देखें, बहुवचन

— ssmith

Answer 1

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

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

Comments

बिल्कुल सही! मुझे हमेशा लगता है कि सॉफ्टवेयर "कंप्यूटर साइंस" के अंतर्गत आता है। मैं हार्डवेयर के लिए तर्क देख सकता हूं, लेकिन सॉफ्टवेयर बहुत ही बेकार विज्ञान के लिए बनाता है!

— जोसेफ फेरिस

अफसोस की बात है कि यह संसाधन अब उपलब्ध नहीं है :(।

@ नील्स डब्ल्यू यह ऊपर है, शायद यह केवल अस्थायी था।

— uthomas

Answer 2

मैंने तीन किताबें पढ़ीं और तब तक पैटर्न को बहुत अच्छी तरह से नहीं समझा, जब तक कि मैंने ओरीली द्वारा हेड फर्स्ट डिज़ाइन पैटर्न नहीं पढ़ा । इस पुस्तक ने मेरी आँखें खोलीं और वास्तव में अच्छी तरह से समझाया।

Comments

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

— टिम व्हिटकोम्ब

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

— छिपकली

आपने 3 पुस्तकों को पढ़ने का उल्लेख किया है..क्या आपने इसे भी पढ़ा है? amazon.com/ ... यदि हां, तो आपने क्या सोचा था?

— शिवबाबू

मैं 2006 में फ्रांस के

— नांतेस

इस पुस्तक को पढ़ने के बाद, OO ने समझदारी दिखाई। @SimpleFellow GoF पुस्तक सुस्त है। डिज़ाइन पैटर्न के बारे में पूर्व जानकारी के बिना यह आपको कुछ ही समय में सोने के लिए मिलता है। हालांकि यह एक अच्छा (है ) संदर्भ पुस्तक और DDD और EAA के पी के साथ-साथ किसी भी पेशेवरों लाइब्रेरी का हिस्सा होना चाहिए।

— mbx

Answer 3

इस तरह के और पुराने प्रश्न के लिए मेरे दो सेंट

कुछ लोगों ने पहले से ही उल्लेख किया है, अभ्यास और refactoring। मेरा मानना ​​है कि पैटर्न के बारे में जानने का सही क्रम यह है:

1. जानें टेस्ट ड्रिवेन डेवलपमेंट (TDD)
2. रिफैक्टरिंग सीखें
3. पैटर्न सीखें

ज्यादातर लोग 1 को अनदेखा करते हैं, कई लोग मानते हैं कि वे 2 कर सकते हैं, और लगभग हर कोई 3 के लिए सीधे जाता है।

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

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

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

Comments

क्या आप TDD के लिए कुछ पुस्तकों की सिफारिश कर सकते हैं और C ++ में

— प्रमुखता से रिफ्लेक्ट कर सकते हैं

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

— सिस्टमैटिकफ्रैंक

Answer 4

डेरेक बानस ने यूट्यूब ट्यूटोरियल को डेसिंग पैटर्न के लिए बनाया है जो मुझे बहुत पसंद है:

http://www.youtube.com/playlist?list=PLF206E906175C7E07

वे समय में थोड़े कम हो सकते हैं, लेकिन उनकी समय और प्रस्तुति उन्हें सीखने में बहुत आनंद देती है।

Answer 5

अभ्यास, अभ्यास, अभ्यास।

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

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

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

यह वास्तव में कोडिंग के समान है; K & R, C के लिए "बाइबिल" हो सकता है, लेकिन इसे कई बार कवर-टू-कवर पढ़ना सिर्फ एक व्यावहारिक अनुभव नहीं देता है; अनुभव के लिए कोई प्रतिस्थापन नहीं है।

Comments

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

— २०:४

Answer 6

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

यदि आप उनके द्वारा हल की गई समस्याओं से पीड़ित नहीं हुए हैं तो आप उनकी पूरी तरह से सराहना नहीं कर सकते। और कृपया ध्यान रखें कि वे चांदी की गोलियां नहीं हैं - आपको उन्हें याद करने की ज़रूरत नहीं है और इसे मक्खी पर लागू करने के लिए कड़ी मेहनत करनी चाहिए। मेरे दो सेंट..

Answer 7

अपने आप से ये सवाल पूछें:

वो क्या करते हैं?

वे क्या करते हैं / युगल?

आपको उनका उपयोग कब करना चाहिए?

आपको उनका उपयोग कब नहीं करना चाहिए?

क्या गायब भाषा सुविधा उन्हें दूर जाना होगा?

इसका उपयोग करके आप कौन से तकनीकी ऋण लेते हैं?

क्या काम करने का एक सरल तरीका है?

Comments

और अंत में अपने आप से पूछें कि उपरोक्त सभी सवालों के जवाब कहां से मिलेंगे

— जतिन धूत

@ जतिनधूत सोच कर ..

— gtrak

Answer 8

मैंने पाया है कि कुछ पैटर्नों के लाभों को समझना या समझना थोड़ा कठिन है, जब तक कि वे उन समस्याओं को नहीं समझते जो वे हल करते हैं और दूसरे (बदतर) तरीके लागू किए गए हैं।

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

सौभाग्य

Comments

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

— फुहरमेनटर

Answer 9

बहुत अच्छे उदाहरण दिए गए हैं। मैं एक जोड़ना चाहूंगा:

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

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

दी, यह वास्तव में एक 21-दिनों का उत्तर है कि आप ऐसा नहीं करते हैं, लेकिन मेरे अनुभव में यह आपको मामले में एक अच्छी जानकारी देने की सबसे अधिक संभावना है।

Answer 10

क्या आपने एलन शालोवे द्वारा "डिज़ाइन पैटर्न समझाया" पढ़ा है।

यह पुस्तक अन्य डिज़ाइन पैटर्न की किताबों से बहुत अलग है क्योंकि यह बहुत अधिक पैटर्न का कैटलॉग नहीं है, लेकिन मुख्य रूप से एक समस्या स्थान को डिकम्पोज करने का एक तरीका प्रस्तुत करता है जो आसानी से पैटर्न को मैप करता है।

समस्याओं को दो भागों में विघटित किया जा सकता है: जो चीजें सामान्य हैं और जो चीजें बदलती हैं। एक बार यह पूरा हो जाने के बाद, हम सामान्य चीजों को एक इंटरफेस में मैप करते हैं, और एक कार्यान्वयन के लिए अलग-अलग चीजें। संक्षेप में, कई पैटर्न इस "पैटर्न" में आते हैं।

उदाहरण के लिए, रणनीति पैटर्न में, सामान्य चीजों को रणनीति के संदर्भ के रूप में व्यक्त किया जाता है, और चर भागों को ठोस रणनीतियों के रूप में व्यक्त किया जाता है।

मैंने पाया कि यह पुस्तक अन्य पैटर्न की किताबों के विपरीत उत्तेजक है, जो मेरे लिए, फोन बुक पढ़ने के समान उत्साह की डिग्री है।

Answer 11

क्या आपने गैंग ऑफ फोर बुक की कोशिश की है?

डिजाइन पैटर्न: पुन: प्रयोज्य वस्तु-उन्मुख सॉफ्टवेयर के तत्व

Comments

मैं उस पुस्तक को "आंख खोलने वाली" पुस्तक के रूप में सुझा नहीं

— जियो

मैं इसे आंख बंद करने वाली पुस्तक के रूप में सुझाऊंगा। सोने से पहले इस टोम के कुछ पृष्ठ और आपकी अनिद्रा अतीत की बात होगी।

— डोनल

इस किताब को पढ़ते हुए दिन के बीच में सोते हुए महसूस करने के बाद मैं यहाँ आया। 'समझ डिजाइन पैटर्न' के लिए खोज की। पद पाया। ऊपर टिप्पणी मिली। मेरा दिन बना दिया। दूसरों के लिए सहमत हैं, इसकी एक आंख बंद करने वाली पुस्तक

— लक्ष्य

Answer 12

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

Answer 13

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

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

Answer 14

मैं HeadFirst DesignPattern की सलाह देता हूं। पुस्तक पढ़ना पर्याप्त नहीं है, अवधारणाओं को आत्मसात करने के बाद आपको अपने दिमाग में बहुत सारे सवालों के जवाब तलाशने की जरूरत है और वास्तविक जीवन के अनुप्रयोगों का पता लगाने की कोशिश करें जहां इन पैटर्नों का उपयोग किया जा सकता है। मैं भी ऐसा ही कर रहा हूं और सवाल पूछना शुरू कर रहा हूं, यहां तक ​​कि सवाल भी मूर्खतापूर्ण लगते हैं।

Answer 15

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

Answer 16

मैं सर्वश्रेष्ठ पुस्तक के बारे में नहीं जानता, लेकिन शुद्धतावादी डिजाइन पैटर्न: पुन: प्रयोज्य वस्तु-उन्मुख सॉफ्टवेयर के तत्व कह सकते हैं

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

अभ्यास - अभ्यास - अभ्यास।

Answer 17

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

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

Answer 18

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

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

Answer 19

यह धारणा कि डिज़ाइन पैटर्न को पढ़ते हैं, उन्हें कोड करने का अभ्यास करते हैं, वास्तव में IMO की मदद करने वाला नहीं है। जब आप इन पुस्तकों को पढ़ते हैं 1. उस मूल समस्या की तलाश करें जो एक विशेष डिज़ाइन पैटर्न को हल करती है, जिसके साथ क्रिएशनल पैटर्न शुरू करना आपकी सबसे अच्छी शर्त है। 2. मुझे यकीन है कि आपने अतीत में कोड लिखा है, विश्लेषण करें कि क्या आपने उन्हीं समस्याओं का सामना किया है जो डिजाइन पैटर्न का उद्देश्य समाधान प्रदान करना है। 3. फ़ैक्टर कोड को फिर से डिज़ाइन / पुन: डिज़ाइन करने का प्रयास करें या शायद नए सिरे से शुरू करें।

संसाधनों के बारे में आप इनकी जांच कर सकते हैं

1. www.dofactory.com
2. डिज़ाइन पैटर्न: एरच गामा, रिचर्ड हेल्म, राल्फ जॉनसन और जॉन एम। विलीसाइड द्वारा पुन: प्रयोज्य वस्तु-उन्मुख सॉफ़्टवेयर (एडिसन-वेस्ले व्यावसायिक कम्प्यूटिंग श्रृंखला) के तत्व।
3. मार्टिन फाउलर द्वारा एंटरप्राइज एप्लिकेशन आर्किटेक्चर के पैटर्न

1 त्वरित शुरुआत है, 2 गहराई से अध्ययन में होगा। 3 आपको समझाएगा या आपको यह सोचना चाहिए कि आपने उद्यम सॉफ्टवेयर में 2 फिट में क्या सीखा।

मेरे 2 सेंट ...

Answer 20

मुझे लगता है कि डिजाइन पैटर्न का अध्ययन करना भी मुश्किल है। आपको OOP के बारे में और अधिक जानकारी और मध्यम से बड़े अनुप्रयोग विकास के साथ कुछ अनुभवों को जानना होगा। मेरे लिए, मैं चर्चा करने के लिए डेवलपर्स के एक समूह के रूप में अध्ययन करता हूं। हम पैटर्न पैटर्न को पूरा करने के लिए एक लर्निंग गाइड टू डिजाइन पैटर्न का पालन करते हैं। सी # और जावास्क्रिप्ट डेवलपर्स एक साथ शामिल हैं। मेरे लिए यह फैंसी बात है कि C # डेवलपर जावास्क्रिप्ट में कोड लिखता है और जावास्क्रिप्ट डेवलपर C # कोड के लिए भी यही काम करता है। एक बैठक छोड़ने के बाद मैंने समीक्षा करने के लिए घर पर कुछ किताबें पढ़ीं और पढ़ीं। मेरे दिमाग में अधिक समझने और याद रखने का बेहतर तरीका यह है कि यहाँ पर C # और JavaScript दोनों उदाहरणों में http://tech.wowkhmer.com/category/Design-Patterns.aspx के साथ ब्लॉगिंग करें ।

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

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

फैक्टरी विधि:

पढ़ें दुनिया: मैं सिर्फ पैसे देता हूं $ 5, $ 10 या $ 20 और यह पिज्जा का उत्पादन करेगा बिना कुछ जाने कैसे यह उत्पादन करता है, मुझे बस एक छोटा, मध्यम या बड़ा पिज्जा मिलता है जो पैसे के इनपुट पर निर्भर करता है ताकि मैं खाऊं या जो भी करूं।

प्रोग्रामिंग: ग्राहक सिर्फ फैक्टरी मूल्य के लिए $ 5, $ 10 या $ 20 के पैरामीटर मान को पास करता है और यह पिज्जा ऑब्जेक्ट को वापस कर देगा। तो ग्राहक उस वस्तु का उपयोग कर सकता है बिना यह जाने कि यह कैसे प्रक्रिया है।

मुझे यकीन नहीं है कि यह आपकी मदद कर सकता है। यह बैठक में शामिल होने वाले लोगों के ज्ञान के स्तर पर निर्भर करता है।

Comments

जवाब में दूसरा लिंक मर चुका है।

— पांग

Answer 21

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

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

Answer 22

एक शुरुआत के लिए, हेड फर्स्ट डिज़ाइन पैटर्न करते हैं, एक बार जब हम सभी पैटर्न से परिचित हो जाते हैं, तो उन पैटर्न पर वास्तविक समय की वस्तुओं की कल्पना करने की कोशिश करें।

पुस्तक आपको मूल अवधारणाओं को समझने में मदद करेगी, जब तक कि आपने वास्तविक दुनिया में लागू नहीं किया है जब तक कि आप डिजाइन विवरण के एक मास्टर नहीं होंगे