कौन से डिज़ाइन पैटर्न सबसे खराब या सबसे संकीर्ण रूप से परिभाषित हैं? [बन्द है]

Question

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

इसलिए, मेरा प्रश्न मेरे भविष्य के करियर के संबंध में है और प्रबंधक प्रकारों के बारे में मेरा उत्तर यादृच्छिक पैटर्न-नामों को फेंक रहा है:

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

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

Comments

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

— थियोडोर नॉरवेल

The गैंग ऑफ़ फोर ’पुस्तक में सभी।

— मील्स राउत

Answer 1

मैं बुरे पैटर्न में विश्वास नहीं करता, मुझे विश्वास है कि पैटर्न बुरी तरह से लागू हो सकते हैं!

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

इस उत्तर के लिए मैंने केवल GOF पैटर्न पर विचार किया। मैं सभी संभावित पैटर्न को अच्छी तरह से नहीं जानता कि उन्हें भी ध्यान में रखना चाहिए।

Comments

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

— माइकल के

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

— क्वेंटिन-स्टारिन

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

— Les Hazlewood

@LesHazlewood अपर्याप्त प्रोग्रामिंग भाषाओं के लिए केवल आगंतुक नहीं है? एमएल जैसी भाषाओं (हास्केल, एसएमएल, ओकेएमएल, आदि) में बीजगणितीय डेटाैटिप्स ("स्टेरॉयड पर संघ") और पैटर्न मिलान ("स्टेरॉयड पर स्विच") है, जो विज़िटर की तुलना में सरल कोड का उत्पादन करते हैं, फिर भी कंपाइलर द्वारा पूरी तरह से जांच की जाती है। आगंतुक की तुलना में, आपके पास बहुत सी विधियाँ नहीं हैं, जिनके हिस्से की स्थिति आपको ऑब्जेक्ट गुणों के माध्यम से मैन्युअल रूप से प्रबंधित करने की आवश्यकता है। एमएल जैसी भाषाओं में, और सभी मामलों में अंतर पूरा होना चाहिए, अन्यथा यह संकलन नहीं करेगा।

— वोग

Answer 2

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

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

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

Comments

पूर्ण रूप से। पैटर्न अच्छे या बुरे नहीं हैं, वे अच्छी तरह से लागू होते हैं या गलत तरीके से लागू होते हैं।

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

— माइकल के

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

— रोब क्रॉफोर्ड

Answer 3

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

अन्य लोग पहले से ही सिंगलेट्स की मेरी व्यक्तिगत घृणा के समान व्यक्त कर चुके हैं, इसलिए मैं यहां पर विस्तार नहीं करने जा रहा हूं।

Answer 4

सिंगलटन। यह GOF पैटर्न पर है जिसे अब अधिक बार एंटी-पैटर्न कहा जाता है। इसका एक कारण यह है कि सिंगलटन परीक्षण के लिए कोड को अधिक कठिन बनाता है।

Comments

सिंगलटन पैटर्न में कई मूलभूत खामियां हैं, सबसे अच्छी तरह से इस लेख में चित्रित किया गया है स्टीव येजे - सिंगलटन माना जाता स्टुपिड

— ओसोडो

Slomojo: अच्छा लेख। मैं अब से इसे 'सिंपलटन पैटर्न' कहने जा रहा हूं:-)

— कोई भी

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

— डंक

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

— क्वेंटिन-स्टारिन

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

— मृतक प्रत्यय

Answer 5

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

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

और टोर्क्स, एमवीवीएम नरक के रूप में मुश्किल है, और बस छोटी अवधि की परियोजनाओं के लिए इसके लायक नहीं है।

डॉ। डब्ल्यूपीएफ ने अपने लेख एमवी-पू में इसके बारे में एक विडंबनापूर्ण पोस्ट किया ।

Comments

@ अक्कू: आपको पता होना चाहिए कि इसका उपयोग कैसे करना है, इसलिए आप यह तय कर सकते हैं कि यह आपके प्रोजेक्ट के लिए उपयुक्त है या नहीं। तो हाँ, यह WPF विकास के लिए आवश्यक है, और बहुत उपयोगी है।

— स्टीवन ज्यूरिस

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

— बीके

Answer 6

GOF पुस्तक में कुछ पैटर्न C ++ - विशिष्ट हैं, इस अर्थ में कि वे प्रतिबिंब वाली भाषाओं में कम लागू हैं, उदाहरण के लिए जावा में प्रोटोटाइप पैटर्न कम महत्वपूर्ण नहीं है।

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

Comments

GOF का अधिकांश हिस्सा केवल स्थैतिक वर्ग आधारित OOP पर लागू होता है। उस तरह की भाषाओं से कभी थोड़ा बहुत भटका और किताब महज एक मनोरंजन का किस्सा बन गई।

— जेवियर

Answer 7

मुझे सबसे अधिक पछतावा होता है (हालांकि सबसे अधिक उत्साह से नहीं): जब मुझे सिर्फ एक फ़ंक्शन बनाना चाहिए था लेकिन मैंने एक OOP समाधान लागू किया।

Comments

क्यूं कर? इससे आपको क्या पछतावा हुआ? कृपया अपने उत्तर का विस्तार करें और अपना अनुभव जोड़ें।

— वाल्टर

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

— अक्कू

KISS आप इसे एक समारोह पहले, तो एक वर्ग के लिए refactor अगर जरूरत बनाने निकलता है।

— ईवा

Answer 8

फैक्टरी। मैंने कोड को इसे लागू करते देखा है जो केवल एक प्रकार बनाता है। यह पूरी तरह से बेकार कोड IMO है। यह मदद नहीं करता है कि ऑनलाइन कई उदाहरण पूरी तरह से वंचित हैं। पिज्जा फैक्ट्री?

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

Comments

हाँ, पिज्जा का कारखाना, हेड फर्स्ट डिज़ाइन पैटर्न के लिए धन्यवाद ~

— निंग

Answer 9

एकाकी वस्तु

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

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

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

आगंतुक

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

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

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

Comments

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

— डंक

Answer 10

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

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

Comments

मुझे यह भी लगता है कि एमवीसी का उपयोग हर जगह किया जाना चाहिए, लेकिन हर जगह उसी तरह लागू नहीं किया जाना चाहिए। और कई लोग इसे समझ नहीं पाते हैं। जब मैंने पहली बार इसका उपयोग करना चाहा, तो मैंने मॉडल, व्यू (एक विंडोज़ फॉर्म) और नियंत्रक नाम की तीन कक्षाएं बनाईं। यह एक गड़बड़ थी, क्योंकि एमवीसी के लिए फॉर्म नहीं बनाए गए थे।

— अक्कू

Answer 11

केवल बुरे लोग ही बुरे पैटर्न नहीं हैं।

मैं बहुत आसानी से आसानी से पढ़ने योग्य कोड प्राप्त कर सकता हूं जो कुछ स्पष्ट करता है लेकिन कुछ क्रियात्मक मैश की तुलना में थोड़ा वर्बोज़ है या नहीं (कतार दुष्ट खलनायक संगीत) फिर से प्रयोग करने योग्य (हांफता है) InheritAbstractTemplateFaucetSink<Kitchen>।

पुन: प्रयोज्य कोड महान है! संभावना है कि आप ऐसा कोड नहीं लिख रहे हैं जो किसी अन्य एप्लिकेशन के लिए पुन: उपयोग किया जाएगा या किसी अन्य एप्लिकेशन के लिए फिर से लिखना होगा, आपको कुछ अन्य एप्लिकेशन के कोड को फिर से उपयोग करने के कुछ पागल प्रयास की तुलना में कम समय लगेगा।

आगे पढ़ने की दरार के लिए पॉज़िक्स हेडर या क्लिब के साने कार्यान्वयन में कुछ सी कोड खोलें और पैटर्न को स्पॉट करें। यह कोड दुनिया के कुछ सबसे चतुर और सबसे समर्पित प्रोग्रामरों द्वारा लिखा गया था। क्या आप जानते हैं कि आप कितने सार फैक्ट्री पैटर्न देख रहे हैं? ... कोई नहीं!। यहां तक ​​कि बेहतर संभावनाएं हैं यदि आप व्हाट्स के अन्य भागों को समझते हैं, तो आपको तर्क को समझने और ट्रेस करने में बहुत आसान लगेगा।

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

इसके साथ मैं आपको कंप्यूटर विज्ञान में सबसे अच्छा (प्रासंगिक) उद्धरण के साथ छोड़ दूँगा।

" सॉफ्टवेयर डिज़ाइन के निर्माण के दो तरीके हैं: एक तरीका यह है कि इसे इतना सरल बना दिया जाए कि जाहिर तौर पर कोई कमी न रह जाए, और दूसरा तरीका यह है कि इसे इतना जटिल बना दिया जाए कि कोई स्पष्ट कमी न रहे। पहला तरीका कहीं अधिक कठिन है। । "

• टोनी होरे (क्विकॉर्ट के आविष्कारक, आधुनिक ओएस डिजाइन के पिता, होरे तर्क के निर्माता, और ट्यूरिंग पुरस्कार प्राप्तकर्ता)

Answer 12

मैं निश्चित रूप से सहमत हूं कि अधिकांश पैटर्न के लिए एक समय है, और आप कई पैटर्न का दुरुपयोग कर सकते हैं। मुझे पता है कि मैंने अतीत में सबसे अधिक दुरुपयोग किया है जो कि सार टेम्पलेट पैटर्न है। पूर्ण सीमा तक इसे ASP.NET वेबफॉर्म के रूप में जाना जाता है।