2010-01-13 12 views
5

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

मैं एक वेब डेवलपर हूं (मैं Django का उपयोग करता हूं, और तर्क को अलग करने से परिचित हूं), लेकिन मैं डेस्कटॉप-ऐप कंपनी में काम करता हूं। वे हमेशा सिंगलेट के बारे में बात कर रहे हैं, और मैं भूल जाता हूं ... लेकिन यह मुझे कोई सुराग नहीं छोड़ता है!

+0

समुदाय विकी .... – jldupont

+0

निश्चित रूप से, समुदाय विकी। – TIMEX

+0

बस अपने आप को सबसे प्रासंगिक पुस्तक प्राप्त करें और सभी के माध्यम से जाओ। –

उत्तर

10

सिंगलटन भूल जाओ। यह भ्रमित और शायद ही कभी जरूरी है।

राज्य, रणनीति और कमान जानें। वे हर समय इस्तेमाल होते हैं।

राज्य किसी भी चीज़ के लिए तर्क है जो वस्तु की स्थिति पर निर्भर करता है। संक्षेप में, प्रत्येक if-statement संभवतः राज्य के माध्यम से बेहतर किया जा सकता है। गंभीरता से। बहुत सारे अगर-कथन एक कोड गंध हैं और इंगित करते हैं कि वहां मौजूद राज्यव्यापी प्रसंस्करण है जो पूरे स्थान पर फैली हुई है।

रणनीति किसी भी "प्लग-इन" या "विस्तार" या "विकल्प" प्रसंस्करण के लिए है।

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

+0

+1। सबसे उपयोगी चीज जो मैंने कभी सीखा है, डिजाइन पैटर्न के अनुसार। सिंगलटन 'भूल' कहने के लिए – GSto

+0

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

+0

@ डेवसिम्स मैं आपके साथ सहमत हूं। मेरा पसंदीदा उदाहरण डेटाबेस कनेक्शन ऑब्जेक्ट है। अगर हमें इसे सिस्टम में हर विधि में पास करना है, तो हम पागल हो जाएंगे। – dotslash

11

एमवीपी या MVC

Model View Presenter या Model View Controller

अधिक architecural पैटर्न लेकिन neverless, वे डिजाइन पैटर्न का एक संयोजन कर रहे हैं।

+5

काफी बोल्ड स्टेटमेंट। मैं कई परिदृश्य देखता हूं जहां एमवीसी या तो अनुपयुक्त या सिर्फ व्यर्थ ओवरहेड होगा। –

+1

मैं असहमत हूं। टेस्टेबिलिटी के लिए, और एएसपी.नेट एमवीसी एट अल जैसे ढांचे के साथ, शायद यह अधिक दर्द है कि इस तरह के पैटर्न का पालन न करें। – Finglas

+3

जबकि "उनके बिना कोई वेब ऐप नहीं होना चाहिए" बहुत बोल्ड हो सकता है, मैं तर्क दूंगा कि "कोई वेब ऐप डेवलपर उनके बारे में नहीं होना चाहिए"। –

2

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

0

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

+1

क्या आपका मतलब एमवीवीएम या मॉडल व्यू व्यू मॉडेल नहीं है? यदि यह मेरे लिए एक नया नहीं है। – Finglas

1

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

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

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

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

1

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

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

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

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

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

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

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

संबंधित मुद्दे