'
'डिज़ाइन पैटर्न एक्सपोज़्ड' श्रृंखला की पहली पोस्ट में आपका स्वागत है। इस श्रृंखला में हम खरोंच से प्रत्येक डिजाइन पैटर्न को उजागर करने जा रहे हैं।
बस एक प्रोग्रामिंग भाषा और इसके निर्माण को जानना आपको बेहतर प्रोग्रामर या डेवलपर नहीं बनाएगा। यह सॉफ्टवेयर बनाने के लिए डिज़ाइन पैटर्न का ज्ञान आवश्यक है जो आज और भविष्य में भी काम करेगा।
कई डेवलपर्स पहले से ही उन डिज़ाइन समस्याओं के बारे में जानते हैं जो आप अभी सामना कर रहे हैं या भविष्य में सामना करेंगे। उन्होंने उस समस्या से निपटने का एक मानक तरीका निर्दिष्ट किया है। इसलिए डिजाइन पैटर्न का उपयोग करके आपको सिद्ध तकनीकों का उपयोग करने का लाभ मिलता है।
प्रत्येक डिज़ाइन पैटर्न एक विशेष प्रकार की स्थिति को हल करने के लिए होता है ऐसी परिस्थितियाँ हो सकती हैं जहाँ एक से अधिक डिज़ाइन पैटर्न का उपयोग किया जा सकता है।
जावा में स्कैनर वर्ग क्या है
अधिकांश प्रोग्रामर डिजाइन पैटर्न, अनावश्यक कोड या तंग-युग्मन के बारे में परेशान किए बिना बस उस समस्या को हल करने का प्रयास करते हैं। लेकिन अच्छे प्रोग्रामर अलग तरह से शुरू होते हैं। वे आज की आवश्यकताओं, भविष्य की आवश्यकताओं, कोड के रखरखाव और कोड के पुन: प्रयोज्य के बारे में सोचते हैं।
अच्छे प्रोग्रामर एक बार कोडिंग शुरू करने की जल्दी में नहीं होते हैं, जब उन्हें आवश्यकता होती है। वे बैठते हैं और इस समस्या के बारे में सोचते हैं कि क्या उनका डिज़ाइन काम करेगा। यदि हाँ, तो क्या यह 6 महीने के बाद काम करेगा, जब आवश्यकताएं बदल जाएंगी।
अच्छे प्रोग्रामर अपनी कलम और कागज लेकर जाते हैं और अपनी कक्षाओं और कक्षाओं के बीच के संबंधों को डिजाइन करना शुरू करते हैं। वे अपने डिजाइन में ढीले युग्मन और उच्च सामंजस्य प्राप्त करने की कोशिश करते हैं, इन सभी को करते हुए उनके दिमाग में ऑब्जेक्ट ओरिएंटेड सिद्धांत होते हैं। वे तुरंत निम्न-स्तरीय कोड के अंदर नहीं जाते हैं। लचीला और पुन: प्रयोज्य सॉफ्टवेयर डिजाइन करने के लिए, आपको इस दृष्टिकोण का पालन करना चाहिए अन्यथा आप हमेशा अपने आप को संशोधित कोड पाएंगे जो आपने पहले लिखा था।
केवल एक चीज है जो सॉफ्टवेयर उद्योग में स्थिर है और वह है खुले पैसे। आवश्यकताएँ निश्चित रूप से बदलती रहेंगी। तो हम कैसे सॉफ़्टवेयर डिज़ाइन करते हैं जो आपका कोड आसानी से भविष्य की आवश्यकताओं के अनुकूल हो सकता है? इसके लिए आपको जल्दी शुरुआत करनी होगी, और इसे इस तरह से डिजाइन करना होगा कि भविष्य की आवश्यकताएं आपके पिछले कोड को न तोड़ें।
मैं वह कैसे कर सकता हूं?
खैर, यह उन सिद्धांतों के आधार पर डिज़ाइन सिद्धांत और डिज़ाइन पैटर्न का पालन करके किया जा सकता है।
अब, कोडिंग में गोता लगाएँ और एक बेहतर प्रोग्रामर बनने के लिए यात्रा शुरू करें। इस पोस्ट में, हम सबसे महत्वपूर्ण पैटर्न में से एक को उजागर करने जा रहे हैं - रणनीति पैटर्न ।
जब मैं कहता हूं कि यह सबसे महत्वपूर्ण समस्या है जो रणनीति पैटर्न द्वारा हल की गई सामान्य समस्या पर निर्भर करती है।
स्ट्रैटेजी पैटर्न क्या है?
यहाँ 'गैंग ऑफ़ फोर' पुस्तक से सीधे परिभाषा दी गई है:रणनीति पैटर्न का उपयोग एल्गोरिदम के एक विनिमेय परिवार को बनाने के लिए किया जाता है जिसमें से आवश्यक प्रक्रिया को रन-टाइम पर चुना जाता है”।
मामले में आप हैंसमझने में सक्षम नहीं है, चिंता मत करो, हम इसे एक में समझाने जा रहे हैंसरलमार्गआप के लिएसमझ गए।
आइए पहले समस्या को समझते हैं और फिर हम देखेंगे कि रणनीति पैटर्न कैसे हल कर सकता है।
उपरोक्त यूएमएल आरेख में, हमारे पास पशु सार वर्ग और दो ठोस कक्षाएं, डॉग एंड बर्ड, पशु सुपर क्लास से फैली हुई हैं।
तो एक पशु अमूर्त वर्ग और दो ठोस वर्गों, डॉग और बर्ड को परिभाषित करते हैं।
उपरोक्त डिज़ाइन के बारे में आप क्या सोचते हैं? हमारे डिजाइन में एक बड़ी गलती है।
सभी जानवर उड़ नहीं सकते हैं, जैसे कि उपरोक्त मामले में एक कुत्ता उड़ नहीं सकता है। लेकिन फिर भी इसमें 'मक्खी' का व्यवहार है।
हमने एनिमल क्लास के अंदर अमूर्त मक्खी () विधि लिखकर गलती की। यह डिज़ाइन प्रत्येक उप-वर्ग के कुत्ते, पक्षी, पेंगुइन, मगरमच्छ, हंस आदि को मक्खी () विधि को लागू करने के लिए मजबूर करेगा।
हमें समझना चाहिए कि उड़ान एक ऐसी क्षमता है जो सभी जानवरों के पास नहीं होगी। पशु अमूर्त वर्ग में मक्खी () विधि प्रदान करके हमने सभी उप-वर्गों में उड़ने की क्षमता निर्धारित की है जो कि सभी उप-वर्गों के लिए सही नहीं है।
आप सोच सकते हैं कि उप-वर्गों में फ्लाई विधि को लागू करने में क्या समस्या है। हालाँकि आप गैर-फ़्लाइंग पशु उप-वर्गों में फ्लाई () पद्धति को केवल 'I can’t fly' नहीं छाप सकते हैं। लेकिन समस्या यह है, आप अभी भी गैर-उड़ान वाले जानवरों को मक्खी का व्यवहार दे रहे हैं। यह सही नहीं है।
कुत्ते को बुलाना कैसा लगता है। () या क्रोकोडाइल.फ्लाई ()।
तो, अब हम समझ गए हैं कि हमारा डिज़ाइन सही नहीं है और हमें पशु उप-वर्ग से मक्खी () विधि को हटा देना चाहिए।
हमारी कक्षाओं को इस तरह से डिजाइन करने का दूसरा तरीका क्या है कि हमारा डिजाइन सभी पशु उप-वर्गों को लागू नहीं करता है ताकि उड़ान व्यवहार हो।
एक समाधान जो तुरंत दिमाग में आता है, वह यह है कि हम एक फ्लाइंग इंटरफ़ेस बना सकते हैं जिसमें फ्लाई विधि होती है और केवल ऐसे जानवर जो उड़ सकते हैं, उस फ्लाइंग इंटरफ़ेस को लागू करेंगे। इस तरह हम एक मक्खी के व्यवहार को परिभाषित करने के लिए सभी पशु उप-वर्गों को लागू नहीं करेंगे। तो आइए इस कोड को डिज़ाइन करें।
अब, हमारा पशु वर्ग पशु वर्ग से मक्खी विधि को हटाने के बाद नीचे दिए गए कोड की तरह दिखेगा।
अब फ्लाइंग इंटरफ़ेस को परिभाषित करते हैं
अब, डॉग क्लास को बदल दिया जाएगाजैसानीचे दिए गए कोड और इसे उड़ने का व्यवहार करने की आवश्यकता नहीं है।
आइए हमारे कुछ एनिमल उप-वर्गों को देखें जिनके पास उड़ान का व्यवहार होगा।
हमने अपनी पिछली समस्या को हल कर लिया है, लेकिन हम एक नई मुसीबत में पड़ गए हैं और वह है 'कोड डुप्लीकेशन'।
कहते हैं, हम 100 अलग-अलग फ्लाइंग एनिमल सब-क्लास करने जा रहे हैं। हमें फ्लाई व्यवहार के लिए कोड को डुप्लिकेट करना होगा क्योंकि फ्लाइंग इंटरफ़ेस फ्लाई व्यवहार के लिए कोई भी कार्यान्वयन प्रदान नहीं कर सकता है, और बाद में यदि हम किसी भी उप-वर्ग में फ्लाई () विधि कार्यान्वयन को बदलना चाहते हैं तो हमें उस वर्ग को खोलना होगा और कोड को बदलना होगा। जो बुरा है। हमारे पास कुछ बड़ी कमी है और, यह है कि हम रन-टाइम पर किसी क्लास के फ्लाइंग बिहेवियर को नहीं बदल सकते।
लेकिन इस समस्या से आपको बाहर निकालने के लिए स्ट्रैटेजी पैटर्न नहीं है।
तो चलिए हमारे कोड को रणनीति पैटर्न का उपयोग करने के लिए पुन: फ़िल्टर करें।
फ्लाइंग इंटरफ़ेस जैसा है वैसा ही रहेगा। अब, फ्लाइंग इंटरफ़ेस को लागू करने वाले प्रत्येक फ्लाइंग सब-क्लास के बजाय, हम अलग-अलग कंक्रीट क्लासेस को परिभाषित करने जा रहे हैं जो अलग-अलग फ्लाइंग व्यवहार को लागू करेंगे। आइए देखें कि ऐसा कैसे किया जाता है।
तो, यह सब कैसे काम करता है, आइए देखें TestClass
साल्टस्टैक बनाम कठपुतली बनाम शेफ
रणनीति पैटर्न का उपयोग करके हम अब रन-टाइम में किसी भी जानवर के उड़ान व्यवहार को बदलने में सक्षम हैं और यह उड़ान व्यवहार को निर्दिष्ट करने के लिए किसी भी उप-वर्गों को लागू किए बिना है।
रणनीति पैटर्न का उपयोग कब करें?
जब आप गतिशील रूप से रन-टाइम पर व्यवहार को बदलने में सक्षम होना चाहते हैं।
यह सुनिश्चित करने के लिए कि आप स्पष्ट रूप से रणनीति पैटर्न को एक और उदाहरण लेते हैं।
उपरोक्त कर्मचारी वर्ग में हम उसके पदनाम के आधार पर कर्मचारी का वेतन निर्धारित कर रहे हैं। यदि कोई कर्मचारी 'इंटर्न' है, तो हम वास्तविक वेतन की गणना के लिए मूल वेतन में 10% बोनस जोड़ रहे हैं।
यदि कोई कर्मचारी 'वेब डेवलपर' है, तो हम वास्तविक वेतन की गणना के लिए मूल वेतन में 20% बोनस जोड़ रहे हैं और इसी तरह की प्रक्रिया अन्य प्रकार के कर्मचारियों के लिए है। यद्यपि वास्तविक भुगतान की गणना करने के लिए हमारा एल्गोरिथ्म बहुत आसान है, लेकिन इसे समझना आसान है लेकिन ज्यादातर समय, इसमें कई तुलनाएं और गणना शामिल हैं।
तो, कर्मचारी-वर्ग कोड में क्या गलत है?
खैर, वेतन (getPay ()) की गणना के लिए कोड स्थिर है। मान लीजिए मैं 'इंटर्न' के लिए 10% से 14% तक बोनस बदलना चाहता हूं। मुझे कर्मचारी-वर्ग कोड खोलना होगा और उसे बदलना होगा।
और दूसरी समस्या यह है कि मैं रन-टाइम में किसी कर्मचारी के वेतन एल्गोरिथ्म को नहीं बदल सकता। तो, कैसे करना है? इस तरह की समस्या से निपटने के लिए विशेष रूप से रणनीति पैटर्न का उपयोग किया जाता है।
आइए कोड को रणनीति पैटर्न का उपयोग करने के लिए कोड दें।
मैं वेतन की गणना के लिए कई एल्गोरिदम को परिभाषित करने जा रहा हूं। फिर मैं रन-टाइम पर भुगतान की गणना करने के लिए इनमें से किसी भी एल्गोरिदम का उपयोग कर सकूंगा।
अब, आइए देखें कि कर्मचारी वर्ग कैसे बदलने जा रहा है।
ध्यान दें: मैंने कर्मचारी वर्ग से वेतन गणना तर्क को हटा दिया है और एक सेट PayAl एल्गोरिथम () विधि बनाई है जिसके माध्यम से मैं PayAl एल्गोरिथम को सेट करूँगा जिसका उपयोग मैं वेतन गणना के लिए करना चाहता हूं।
यह मुझे रन-टाइम पर गतिशील रूप से किसी भी PayAlgorithm को निर्दिष्ट करके वेतन की गणना करने की सुविधा देगा। यह भी ध्यान दें कि बाद में अगर मुझे वेतन गणना तर्क को बदलना है तो मैं एक नया PayAl एल्गोरिथम बना सकता हूं और वेतन की गणना करने के लिए इसका उपयोग कर सकता हूं। मुझे पिछले कोड को बदलने की आवश्यकता नहीं है, क्या यह बहुत अच्छा नहीं है?
तो चलिए इसे काम करते हुए देखते हैं।
मुझे उम्मीद है कि आप रणनीति पैटर्न को अच्छी तरह से समझ गए होंगे। किसी चीज़ को सीखने का सबसे अच्छा तरीका अभ्यास करना है।
यदि आपके पास रणनीति पैटर्न या किसी अन्य पैटर्न से संबंधित कोई प्रश्न हैं, तो अपने प्रश्नों को नीचे छोड़ दें।
अगली पोस्ट के लिए बाहर देखें, जहां हम सबसे लोकप्रिय डिज़ाइन पैटर्न, फ़ैक्टरी पैटर्न में से एक को उजागर करेंगे।
तब तक आप इसके साथ कोड प्ले डाउनलोड कर सकते हैं और सुनिश्चित कर सकते हैं कि आप अपने सिर में स्ट्रैटेजी पैटर्न को सीमेंट कर लें।
क्या आप हमसे कोई प्रश्न पूछना चाहते हैं? उन्हें टिप्पणी अनुभाग में उल्लेख करें और हम आपके पास वापस आ जाएंगे।
संबंधित पोस्ट: