डिजाइन पैटर्न स्टिफल क्रिएटिविटी करें


21

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

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

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

तुम क्या सोचते हो?


5
मैं एक पैटर्न लैंग्वेज (किताब, विकिपीडिया लेख नहीं) पढ़ने का सुझाव दूंगा , जिस पर पैटर्न की सॉफ्टवेयर आर्किटेक्चर अवधारणाओं की स्थापना की गई है। वे सिर्फ एक साथ फिट होने के लिए ब्लॉक या पहेली टुकड़ों का निर्माण नहीं कर रहे हैं।

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

2
मुझे नहीं लगता कि दोनों आवश्यक रूप से तुलनीय हैं - डिजाइन पैटर्न शास्त्रीय समाधान नहीं हैं, वे समाधानों की भीड़ के लिए एक दृष्टिकोण हैं।
जोर्मेनो

1
डिज़ाइन पैटर्न के संभावित डुप्लिकेट - क्या आप उनका उपयोग करते हैं? - सवाल अलग लग सकता है, लेकिन इस सवाल के जवाब इस मामले के लिए अच्छी तरह से फिट हैं।
डॉक ब्राउन

2
मैं रचनात्मकता के बारे में नहीं जानता, लेकिन "यह क्या पैटर्न है?" या "क्या इसके लिए कोई पैटर्न है?" प्रश्न यह धारणा देता है कि कुछ देवता सोचते हैं कि हर चीज के लिए एक पैटर्न है।
जेएफओ

जवाबों:


43

आपका अर्थशास्त्र का प्रोफेसर बिलकुल सही है।

सॉफ्टवेयर डिजाइन पैटर्न मुख्य रूप से अनुभवी सॉफ्टवेयर डेवलपर्स के लिए एक दूसरे के साथ संवाद करने का एक तरीका है । वे ज्ञात समस्याओं के स्थापित समाधानों के लिए एक आशुलिपि हैं।

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

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

पैटर्न सीखें। पैटर्न, और उनके उचित उपयोग को समझें। पता है कि पैटर्न के बिना एक ही समस्या को कैसे हल किया जाए (सभी सॉफ्टवेयर पैटर्न मौलिक एल्गोरिदम पर सार हैं)। तब आप आत्मविश्वास के साथ सॉफ्टवेयर पैटर्न का उपयोग करने में सक्षम होंगे, जब यह ऐसा करने के लिए समझ में आता है।


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

18
@ मेहदी जब बहुत से लोगों को एक ही समाधान मिलते हैं, तो उस समाधान को एक पैटर्न कहा जाता है। यह दूसरा तरीका नहीं है - आप पैटर्न को नहीं देखते हैं और उन्हें समाधान के रूप में उपयोग करते हैं, आप समाधान को देखते हैं और पैटर्न पाते हैं।
user253751

13
@ मेहदी मैं और भी शुरुआती लोग देखते हैं जो सोचते हैं कि अगर वे केवल XXX का उपयोग करते हैं तो वे हर बार सही सॉफ्टवेयर बनाएंगे (जहां XXX जो भी उनके बारे में पढ़ा है वह निश्चित रूप से अंतिम है) और फिर हर परियोजना को फिटिंग में यातना देने के लिए निकल जाते हैं। वह पैटर्न।
jwenting

5
@ मेहदी: "जो लोग पैटर्न के बिना समस्या को हल करने के तरीके को समझते हैं, उनके द्वारा" वाक्य को न लें। रॉबर्ट का निश्चित रूप से "उन लोगों द्वारा मतलब है, जिन्होंने इस समस्या को अच्छी तरह से समझ लिया है कि पैटर्न का उपयोग कब करना है और कब नहीं" के बारे में उचित निर्णय लेना है।
डॉक ब्राउन

2
@ डंक मैं एक अच्छी तरह से ज्ञात पैटर्न के शीर्ष पर कुछ रचनात्मक कोशिश कर सकता हूं या मैं इसे खरोंच से बना सकता हूं, लेकिन अन्य चीजों के गुच्छा की कोशिश करने और समझने के बाद कि प्रत्येक पैटर्न के सटीक पेशेवरों और विपक्ष क्या हैं। यदि आप मुझे पहली बार एक घर बनाने और जाने के लिए कहते हैं, और मुझे रचनात्मक होने के लिए कहेंगे, तो मैं कुछ भी ठोस बनाने के लिए दूर नहीं जाऊंगा, क्योंकि यह पहली जगह में बहुत जटिल है। यदि आप एक पैटर्न का उपयोग करने के बजाय रचनात्मक होना चाहते हैं, तो आपको पहले से ही समस्या की ठोस समझ होनी चाहिए, और वर्षों के अनुभव के बाद ही आप इसे हासिल करेंगे ...
Mahdi

21

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

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

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

यदि आप एक समस्या को देखते हैं और अपने आप से पूछते हैं "इसके लिए डिज़ाइन पैटर्न क्या है?", तो आप इसे गलत कर रहे हैं, और आपको एक समाधान देखने की संभावना कम है जो आपको चेहरे पर घूर रहा है।

यदि आप एक समस्या को देखते हैं और अपने आप से पूछते हैं "मैं इसे कैसे हल कर सकता हूं?", तो यदि कोई गैर-पैटर्न समाधान है, तो आप इसे देखेंगे, और यदि कोई पैटर्न फिट बैठता है, तो आप उसे भी देखेंगे।


10

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

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

मुझे लगता है कि हम में से अधिकांश के लिए वही है। यदि कोई आपको DI के बारे में नहीं बताता है - एक अच्छे अभ्यास के रूप में, तो उनके डेवलपर्स को सबक सीखने तक कितने उद्यम अनुप्रयोगों को संघर्ष या असफल होना चाहिए?

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

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


3
"मैंने बहुत कुछ सीखा है, लेकिन वे सभी मूल रूप से असफल थे। मैंने अपनी पूरी कोशिश की, लेकिन अगर कोई वीवीसी वहां से बाहर नहीं होता तो क्या होता? खैर, सरल, मेरा स्रोत कोड बेकार है" - ठोस सोने के शब्द!
अंकुश

5

एक हथौड़ा को मजबूत मत करो, लेकिन हर समस्या का इलाज नेल की तरह न करें

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

आपके प्रश्न को विरोधाभासी बनाना: मुझे ड्राइव करना सीखना तेजी से आगे बढ़ना होगा, या बस धीमी गति से चलना होगा?

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

अपने प्रश्न के दूसरे भाग पर लौटना - क्या आपका प्रोफेसर सही है?

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

यही कारण है कि आप पहले छात्रों को प्रोग्राम करना सिखाते हैं, और पैटर्न को आगे के सेमेस्टर में पेश किया जाता है।


5

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

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

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

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


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

@dotslash उसी कारण से जो IQ टेस्ट मैथ्स / लॉजिक पर भारी पड़ते हैं: उनका कुछ मूल्य होता है और उनका परीक्षण करना आसान होता है। उस ने कहा, एक प्रोग्रामर के रूप में मेरे जॉब करने में मैंने उन सभी के साक्षात्कार में उनका सामना नहीं किया; मैं हालांकि ऑस्ट्रेलियाई हूं, इसलिए शायद फैशन में अंतर है।
बेन

लेकिन कोड के बारे में सोचने के ठोस उदाहरणों को देखने के लिए डिज़ाइन पैटर्न के बारे में एक बढ़िया तरीका नहीं सीख रहा है? यदि आप समस्याओं के बारे में जानना चाहते हैं, तो कोड के बारे में कैसे सोचें अगर समस्याएँ नहीं हैं + सामान्य समाधान जो समस्याओं को हल करते हैं और उदाहरण कोड को हल करते हैं?
एमी ब्लेंकशिप

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

बहुत बढ़िया जवाब। सर्वश्रेष्ठ प्रोग्रामिंग वातावरण पुस्तकालयों या भाषाओं में सबसे दिलचस्प पैटर्न को प्रोत्साहित करेगा, डेवलपर्स को एक उच्च स्तर पर काम करने के लिए मुक्त करेगा। मुझे भाषा निर्भरता के बारे में भी बात पसंद है; कई सामान्य डिजाइन पैटर्न वास्तव में अब अप्रचलित हैं।
फ्रैंक हिलमैन

3

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

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


1

जवाब है, बिल्कुल: हाँ।

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

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

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


3
वे प्रोग्रामिंग (डिजाइन के बजाय) शिक्षण के लिए भयानक शिक्षण उपकरण हैं। वे इंटरनेट के मंचों पर ओह इतने सामान्य प्रश्न का नेतृत्व करते हैं "मैं YYY पैटर्न का उपयोग करके XXX को कैसे लागू कर सकता हूं", जो पूछने के लिए गलत सवाल है, सवाल यह होना चाहिए (जब आप पैटर्न को बाध्य करना चाहते हैं) "क्या पैटर्न उपयुक्त होगा?" XXX को लागू करने के लिए ”।
jwenting

1
योग्य मैंने कहा शिक्षण उपकरण, शिक्षण उपकरण नहीं - यदि कोई सीखना चाहता है;)
रोब

-2

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


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