डिज़ाइन पैटर्न - क्या आप उनका उपयोग करते हैं?

Question

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

क्या वे वास्तव में अधिकांश प्रोग्रामर द्वारा उपयोग किए जाते हैं?

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

और यह भी, क्या आप (प्रोग्रामर) अपने आप को पैटर्न ढूंढ रहे हैं (जहां मैं देखने वाला हूं, वैसे?) जब आप विकास शुरू करते हैं। यदि हां, तो यह निश्चित रूप से एक आदत है जिसे मुझे गले लगाना होगा।

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

Comments

एक सटीक डुप्लिकेट प्रश्न नहीं है, लेकिन मेरा उत्तर समान होगा। programmers.stackexchange.com/questions/70877/…

— pdr

ओवरराइड किए गए अधिकांश "डिज़ाइन पैटर्न" केवल OOP प्रोग्रामिंग के लिए प्रासंगिक हैं। और जब तक संभव हो ओओपी से दूर रहने के कई अच्छे कारण हैं।

— एसके-तर्क

मैं खुद को मिट्टी के बिग बॉल का उपयोग करना चाहता हूं जो मुझे पसंद है। मजाक कर रहा हूं।

— sashoalm

एकमात्र उत्तर "जब उचित हो" के सशर्त बयान के साथ हां है

— ऋग्वेद

Answer 1

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

नौसिखिया प्रोग्रामर डिजाइन पैटर्न का उपयोग नहीं करते हैं। वे डिजाइन पैटर्न का दुरुपयोग करते हैं।

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

अनुभवी प्रोग्रामर डिज़ाइन पैटर्न का उपयोग नहीं करते हैं। डिजाइन पैटर्न उनका उपयोग करते हैं।

Comments

@schlingel - आप ओपी सर को क्यों बुला रहे हैं?

— ऊद

@ मैं इन परिस्थितियों में "सर" कहलाने का अपना अधिकार सुरक्षित रखता हूं और इसका आनंद लेता हूं।

— लूनिवोर

श्रीमान जी हाँ। कोई अपराध नहीं!

— ऊद

सोवियत रूस में .. :)

— सोरेंटिस

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

— गैरेट हॉल

Answer 2

कोई उन्हें पहचानता है या नहीं, अधिकांश प्रोग्रामर पैटर्न का उपयोग करते हैं।

हालांकि दिन-प्रतिदिन के काम के लिए, कोई भी एक पैटर्न को ध्यान में रखते हुए प्रोग्रामिंग शुरू नहीं करता है - एक यह मानता है कि एक पैटर्न कोड में उभरा है और फिर इसे नाम देता है।

कुछ सामान्य पैटर्न कुछ भाषाओं में निर्मित होते हैं - उदाहरण के लिए, कीवर्ड के साथ C # में निर्मित इट्रेटर पैटर्नforeach ।

कभी-कभी आप पहले से ही उस पैटर्न को जानते हैं जिसका उपयोग आप समस्या के सामान्य समाधान के रूप में करेंगे (जैसे रिपॉजिटरी पैटर्न - आप पहले से ही जानते हैं कि आप इन-मेमोरी कलेक्शन के रूप में डेटा का प्रतिनिधित्व करना चाहते हैं)।

Comments

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

— मार्क बूथ

@DeadMG ऐसा क्यों है?

— क्रिश हार्पर

@ डेडएमजी: मैं आँख मूंदकर विचार से अंधी हो गई होगी - मैं नहीं देख सकती कि आपको ऐसा क्यों लगता है कि यह बेवकूफ है

— ?;

@ root45 - आप दोस्त देखते हैं, foreachनिर्माण प्रोग्रामिंग को बहुत आसान बना देता है। अगर किसी संग्रह से अधिक जटिल काम आसान हो तो कोई दूसरों से श्रेष्ठ कैसे महसूस कर सकता है? मैं अपने सभी CRUD ऐप के लिए अभी भी असेंबली में एक कोड के लिए हूं। स्पष्ट रूप से @DeadMG की भावना शुद्ध व्यावहारिक प्रतिभा में से एक है।

— कैओसपांडियन

@DeadMG - जब .NET 1.0 / 1.1 था तब LINQ आसपास नहीं था। yieldया तो मौजूद नहीं था। क्या आपको लगता है कि किसी कीवर्ड को हटाकर पुराने कोड को तोड़ना एक बेहतर विकल्प है?

— ओडेड

Answer 3

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

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

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

यदि यह एक या एक से अधिक मौजूदा पैटर्न का उपयोग करने के लिए निकलता है तो महान, आपके पास तैयार नाम हैं जो दूसरों के लिए आपके कोड को समझना आसान बना देगा।

Comments

+1 जो मैं कहना चाहता था उसके एक महत्वपूर्ण योग के लिए: समस्या पर ध्यान केंद्रित करें, और फिर, और उसके बाद ही, यदि समस्या एक पैटर्न की तरह दिखती है, तो पैटर्न लागू करें।

— जोशुआ ड्रेक

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

— चमत्कारिक काल

Answer 4

सामान्यतया, नहीं। ऐसे समय होते हैं जब पैटर्न मेरे कोड से निकलता है, लेकिन सामान्य तौर पर, मैं उनकी तलाश नहीं करता और मैं निश्चित रूप से नहीं कहता "ओह, ब्रिज पैटर्न मेरी समस्या को हल करेगा!"।

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

Comments

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

— जियोर्जियो

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

— डेनिथ

Answer 5

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

Comments

लिंक ने मेरा दिन बना दिया

— dukeofgaming

आउच। उस वेब-पेज को कुछ पाठ स्वरूपण की आवश्यकता है।

— नेलर

Answer 6

क्या आप उनका उपयोग करते हैं?

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

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

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

क्या आप (प्रोग्रामर) अपने आप को पैटर्न ढूंढ रहे हैं

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

मैं btw देखने वाला हूँ?

चूंकि आप एक छात्र हैं तो आपने आमतौर पर विशिष्ट समस्याओं को नहीं देखा है जो डिजाइन पैटर्न को प्रेरित करते हैं। मैं दृढ़ता से अनुशंसा करता हूं कि आप हेड फ़र्स्ट डिज़ाइन पैटर्न देखें । वे पहले एक डिज़ाइन समस्या पेश करते हैं और फिर दिखाते हैं कि एक विशेष पैटर्न इसे कैसे हल / टाल सकता है।

Answer 7

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

मुझे विश्वास नहीं हो रहा है कि मैंने सार्वजनिक रूप से स्वीकार किया है। मुझे लगता है कि मैंने शायद पिछले कुछ वर्षों में स्थापित किए गए किसी भी गीक क्रेडिट को खो दिया है।

Answer 8

प्रवृत्ति के लिए मत देखो

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

आप पहले से ही एक डिज़ाइन पैटर्न का उपयोग कर रहे होंगे जो अभी तक आविष्कार / निर्दिष्ट नहीं किया गया है।

उनका उपयोग करने की कोशिश मत करो, उनकी शर्तों में सोचने की कोशिश करो

डिजाइन पैटर्न के साथ समस्या यह है कि कभी-कभी प्रोग्रामर अपनी समस्याओं को उन में फिट करना चाहते हैं जब यह दूसरा तरीका है।

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

जंगली में उनके लिए देखो

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

डेटा पैटर्न जैसे अन्य पैटर्न हैं, उदाहरण के लिए अकेले डॉक्ट्रिन प्रोजेक्ट ने उपयोग किया है, सक्रिय रिकॉर्ड पैटर्न (1.x), इकाई प्रबंधक पैटर्न (2.x), कार्य की इकाई , रिपॉजिटरी , क्वेरी ऑब्जेक्ट , मेटाडेटा मैपिंग , डेटा मैपिंग , और अन्य सामान्य तरीके जैसे रणनीति पैटर्न , और डेकोरेटर पैटर्न ।

चुनने के लिए बस इतने सारे दिलचस्प समाधान हैं। मार्टिन फाउलर के एंटरप्राइज आर्किटेक्चर के पैटर्न देखें , डेटा मॉडल पैटर्न भी हैं ।

समय आने पर बस उन्हें सीखें

उन्हें जानें, उन्हें जानें, उन पर जुनूनी और जब समय आएगा तो आपको पता चलेगा कि प्रोग्रामिंग समस्या x को कैसे हल करना है, आप उस समय तक पहले से ही एक बेहतर प्रोग्रामर होंगे।

एक वास्तुकार बनें

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

Answer 9

मैंने C ++ में लगभग 7 साल तक प्रोग्राम किया है और लगभग 2 साल पहले पैटर्न सीखा है। अधिकांश पैटर्न में संभवतः कुछ अनुप्रयोग हैं, लेकिन मेरे उपयोग में, कुछ दूसरों की तुलना में बेहतर हैं। आपको यह सोचना होगा कि आप उनका उपयोग क्यों कर रहे हैं।

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

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

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

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

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

Answer 10

लूनीवर में जोड़ना। मुझे यह पहली पुस्तक के शीर्ष से उद्धृत करना पसंद है

        ## **Three steps to great software** ##     

• सुनिश्चित करें कि सॉफ्टवेयर वही करता है जो ग्राहक चाहता है
• अच्छे ऑब्जेक्ट-ओरिएंटेड सिद्धांतों को लागू करें
• एक बनाए रखने योग्य, पुन: प्रयोज्य डिजाइन के लिए प्रयास करें

यह तीसरे चरण के दौरान है, जब आपका सिस्टम काम कर रहा होता है, तो यह माना जाता है। आने वाले वर्षों के लिए अपने सॉफ़्टवेयर को तैयार करने के लिए पैटर्न लागू करने का समय।

Answer 11

क्या वे वास्तव में अधिकांश प्रोग्रामर द्वारा उपयोग किए जाते हैं?

मैं हां का अनुमान लगाऊंगा। ADO.Net में एक सरल उदाहरण देने के लिए एक DataAdapter वर्ग है, हालांकि आप किस क्षेत्र के विशेषज्ञ के पैटर्न के आधार पर भिन्न हो सकते हैं।

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

नहीं, यह मेरे दिमाग में एक डिजाइन पैटर्न नहीं है। एक डिजाइन पैटर्न कक्षाओं और विधियों की कुछ व्यवस्था करता है जो एक पैटर्न के नुस्खा को परिभाषित करता है।

मैं यह सोचना पसंद करूंगा कि आपने एक सामान्य अभ्यास के रूप में वहां क्या किया है। हालांकि कॉपी और पेस्ट कोडिंग से सावधान रहें।

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

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

Answer 12

लर्निंग पैटर्न केवल कुछ सीखना नहीं है। आप सीखते हैं कि आप प्रोग्रामिंग भाषाओं के साथ क्या कर सकते हैं। मैंने खुद के लिए ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के बारे में बहुत कुछ सीखा है कि कैसे एक पैटर्न काम करता है ( इस मामले में समग्र पैटर्न )।

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

Answer 13

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