2008-08-14 20 views
27

असली दुनिया में डिजाइन पैटर्न की क्या पहुंच है? क्या आप उन्हें अपने दिन-प्रतिदिन नौकरी में उपयोग करते हैं - चर्चा करते हैं कि उन्हें अपने सहकर्मियों के साथ कैसे और कहाँ लागू किया जाए - या क्या वे अकादमिक अवधारणा से अधिक रहते हैं?क्या आप डिज़ाइन पैटर्न का उपयोग करते हैं?

क्या वे वास्तव में आपके काम को वास्तविक मूल्य प्रदान करते हैं? या वे सिर्फ कुछ ऐसा है जो लोग स्मार्ट लगने के बारे में बात करते हैं?

नोट: इस प्रश्न के प्रयोजन के लिए सिंगलटन जैसे 'सरल' डिज़ाइन पैटर्न को अनदेखा करें। मैं आपके कोड को डिजाइन करने के बारे में बात कर रहा हूं ताकि आप मॉडल व्यू कंट्रोलर इत्यादि का लाभ उठा सकें।

उत्तर

54

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

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

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

3

मैं कोशिश करता हूं, हाँ। वे वास्तव में आपके कोड की रखरखाव और पठनीयता में मदद करते हैं। हालांकि, ऐसे लोग हैं जो दुर्व्यवहार करते हैं, आमतौर पर (जो मैंने देखा है) एक प्रणाली को एक ऐसे पैटर्न में मजबूर कर रहा है जो मौजूद नहीं है।

2

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

मैं नहीं कह रहा हूं कि प्रत्येक डिज़ाइन पैटर्न का उपयोग किया जा रहा है लेकिन कई हैं।

2

हाँ हम करते हैं, आमतौर पर ऐसा होता है जब हम कुछ डिजाइन करना शुरू करते हैं और फिर कोई नोटिस करता है कि यह मौजूदा पैटर्न जैसा दिखता है। इसके बाद हम इसे देखते हैं और देखते हैं कि यह हमारे लक्ष्य को प्राप्त करने में हमारी सहायता कैसे करेगा।

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

आपको याद है, हम उनका बहुत उपयोग नहीं करते हैं।

2

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

3

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

+0

लेकिन यदि आप इसका उपयोग करने की कोशिश नहीं करते हैं, तो आप इससे कैसे परिचित हो सकते हैं ?! पहली बार यह चूस जाएगा, लेकिन समय के साथ आप उन्हें उचित रूप से उपयोग करना शुरू कर देंगे। अन्य कार्यों में, आप विफलता के बिना कैसे सफल हो सकते हैं? – ep3static

+0

बेशक आपको प्रयोग करना चाहिए, लेकिन उत्पादन कोड के साथ नहीं। यही वह था जिसके बारे में मैं बात कर रहा था। – Patrik

+0

लेकिन उत्पादन कोड सही परीक्षण नहीं है जो आपने वास्तव में किया है - और अच्छी तरह से काम करता है? –

1

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

1

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

क्या वे महत्वपूर्ण हैं, हां क्योंकि यह आपको एक त्वरित कुशल और आम तौर पर स्वीकार्य तरीके से सॉफ्टवेयर डिज़ाइन के बारे में बात करने का तरीका देता है। क्या आप बेहतर कस्टम समाधान कर सकते हैं, हां (sorta)?

मूल गोफ पैटर्न को उत्पादन कोड से खींचा गया था, इसलिए उन्होंने पहले से ही जंगली में क्या उपयोग किया जा रहा था। वे पूरी तरह से या यहां तक ​​कि ज्यादातर अकादमिक बात नहीं हैं।

1

मुझे आपके मॉडल तर्क को अलग करने के लिए वास्तव में उपयोगी एमवीसी पैटर्न मिलता है, जिसे बिना किसी परेशानी के पुन: उपयोग किया जा सकता है या काम किया जा सकता है। यह आपकी कक्षाओं को डी-युग्मन करने में मदद करता है और यूनिट परीक्षण को आसान बनाता है। मैं recently (हाँ, बेशर्म प्लग यहाँ ...) इसके बारे में लिखा

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

पुल उपयोग किया जाता है जब जब एक साथ दो अलग प्रौद्योगिकियों गोंद करने के लिए कोशिश कर रहा है की कोशिश कर रहा है (जैसे Cocoa and Ruby मैक पर, उदाहरण के लिए)

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

आपको बस सावधान रहने की आवश्यकता नहीं है और architecture astronaut!

9

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

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

मैं व्यक्तिगत रूप से संचार उपकरण के रूप में पैटर्न का उपयोग करता हूं। बस। वे डिजाइन समाधान नहीं हैं, वे सर्वोत्तम प्रथा नहीं हैं, वे टूलबॉक्स में उपकरण नहीं हैं।

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

एंटी-पैटर्न हालांकि पूरी तरह से अलग वर्ग पर हैं।आप वास्तव में सक्रिय रूप से विरोधी पैटर्न से बचें। यही कारण है कि विरोधी विरोधी नाम इतना विवादास्पद है।

अपने मूल प्रश्न पर वापस जाने के लिए:
"क्या मैं डिजाइन पैटर्न का उपयोग करता हूं?", हाँ!
"क्या मैं सक्रिय रूप से डिजाइन पैटर्न की तरफ झुकता हूं?", संख्या

0

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

मैं भी Martin Fowler'sPatterns of Enterprise Application Architecture का बहुत शौकिया हूं। जब कोई समस्या या कार्य स्वयं प्रस्तुत करता है, तो मैं संबंधित अनुभाग (यह ज्यादातर संदर्भ पुस्तक है) पर फ़्लिप करता है और पैटर्न के कुछ अवलोकन पढ़ता है। एक बार जब मुझे सामान्य समस्या और मौजूदा समाधानों का बेहतर विचार हो, तो मुझे लगता है कि मेरे कोड की संभावना लंबे समय तक चलने लगती है जो मेरे कोड को दूसरों के अनुभव के माध्यम से ले जाएगा। मैं बहुत बेहतर निर्णय लेता हूं।

डिजाइन पैटर्न निश्चित रूप से मेरे "भविष्य के लिए" विचारों में एक बड़ी भूमिका निभाते हैं।

1

हां, डिजाइन पैटर्न का वास्तविक रूप से वास्तविक दुनिया में उपयोग किया जाता है - और रोज़ाना जिन लोगों के साथ मैं काम करता हूं।

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

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

4

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

इसके अलावा, यहाँ कुछ अन्य पैटर्न है कि उपयोगी हो सकता है कर रहे हैं:

  • MVVM (मॉडल-व्यू-ViewModel): MVC लिए एक समान पैटर्न; WPF और सिल्वरलाइट अनुप्रयोगों के लिए उपयोग किया जाता है।

  • संरचना: जब आपको ऑब्जेक्ट्स के पदानुक्रम का उपयोग करने की आवश्यकता होती है तो बढ़िया।

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

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

सामान्य डिजाइन पैटर्न में काफी उपयोगी हैं लेकिन आपको उन्हें हर जगह उपयोग नहीं करना चाहिए; बस जहां वे आपकी जरूरतों के लिए उपयुक्त हैं।

1

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

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

जैसा कि आप जानते हैं, विरोधी पैटर्न भी खतरनाक चीज है और ऐसा तब होता है जब आपके पास डिज़ाइन पैटर्न पर कम विशेषज्ञता होती है। और एंटी-पैटर्न को पुन: सक्रिय करना अधिक कठिन है। इस समस्या के बारे में एक अनुशंसित पुस्तक के रूप में कृपया "एंटीपाटरर्न: रिफैक्टरिंग सॉफ्टवेयर, आर्किटेक्चर, और क्राइसिस में प्रोजेक्ट्स" पढ़ें।

1

हां।

हम भी अपने वर्तमान काम में उनका उपयोग कर रहे हैं: COBOL और PL/I के साथ मेनफ्रेम कोडिंग।

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