पैटर्न आधारित प्रोग्रामिंग क्या है?


16

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


12
पैटर्न के साथ जुनून एक तरह से एक विरोधी पैटर्न है
Anto

1
अंतिम बिंदु पर, मैं आंशिक रूप से सहमत हूं। मेरे नाम के कुछ पैटर्न हैं, लेकिन कुछ पाठ्यपुस्तक के पैटर्न एक दूसरे के मामूली रूप से भिन्न होते हैं, और दिलचस्प बात यह है कि आमतौर पर आप विशिष्ट मामले को किसी भी तरह फिट करने के लिए पैटर्न को कैसे अनुकूलित करते हैं, इसलिए आपको निश्चित रूप से चीजों के बारे में हठधर्मी नहीं होना चाहिए।
स्टीव ३४

1
क्या आप एक गतिशील भाषा में प्रोग्रामिंग कर रहे हैं? जिन लोगों को लोग संदर्भित करते हैं उनमें से कई जावा में सीमाओं के आसपास होने के तरीके हैं।
जॉन्पीज

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

जवाबों:


19

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

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

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


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

3
"जुनून" आप आम तौर पर उन लोगों से आते हैं जिन्होंने केवल अवधारणा की खोज की है - ज्यादातर सच, IMHO। ऐसे लोग हैं, मेरा मानना ​​है कि आपको लगता है कि आपको तैयार पैटर्न के साथ एक समस्या का सामना करना होगा ... और यदि आपके समाधान में स्पष्ट पैटर्न शामिल नहीं हैं, तो आपका समाधान गलत है ... हमें पैटर्न सीखने का समय निकालना चाहिए, वे कैसे 'फिर से इस्तेमाल किया, और जब और जब उन्हें इस्तेमाल नहीं करने के लिए - वे हमारे उपकरण बॉक्स का हिस्सा हैं
IAbstract

9

पैटर्न दोनों एक रसोई की किताब में प्रोग्रामर के डिस्टिल्ड नॉलेज हैं, और प्रोग्रामर के लिए संवाद करने का एक उपयोगी तरीका है।

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

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


2
संचार के लिए +1। जब हर कोई एक ही पृष्ठ पर होता है और एक सामान्य लेक्सिकॉन होता है, तो दिन-प्रतिदिन की दिनचर्या बहुत अधिक चिकनी हो जाती है।
Ampt

3

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

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

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

पैटर्न पर कुछ ऑनलाइन ट्यूटोरियल देखें। विकिपीडिया पर लेखों का एक अच्छा सेट है। इस साइट में भी अच्छा है: http://sourcemaking.com/ । यदि आप एक अनुभवी प्रोग्रामर हैं, तो आप पाएंगे कि आप कुछ पैटर्न में आ गए हैं, हो सकता है कि किसी खास नाम से जाने बिना भी कुछ ऐसा ही लागू किया हो।

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

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


1

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

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

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

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