👲🏿 🎅🏻 🖐🏾 थोड़ा जेनेरिक डिज़ाइन पैटर्न के बारे में 👎 🤛🏾 👆🏿

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

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

छह जनरेटर के लिए जिम्मेदार ठहराया जा सकता है:

प्रोटोटाइप (प्रोटोटाइप),
सार फैक्टरी,
फैक्टरी विधि
बिल्डर (बिल्डर),
एकल (सिंगलटन),
आलसी आरंभीकरण।

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

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

कहाँ?
कैसे?
कब?

कहाँ?

तीन पैटर्न इस सवाल का जवाब देते हैं: प्रोटोटाइप, एब्सट्रैक्ट फैक्ट्री, और फैक्ट्री मेथड।

शर्तों के बारे में थोड़ा सा

ओओपी की अवधारणा के ढांचे के भीतर, केवल तीन स्थान हैं जहां सैद्धांतिक रूप से एक नया उदाहरण उत्पन्न करना संभव है।

उत्पाद वह वर्ग है जो तात्कालिक है।
ग्राहक वह वर्ग है जो तात्कालिक उदाहरण का उपयोग करेगा।
साथी - क्लाइंट की दृश्यता के क्षेत्र में कोई भी तृतीय श्रेणी।

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

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

"प्रोटोटाइप"

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

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

यह टेम्प्लेट हमें क्या देता है:

कम कनेक्टिविटी - वर्ग केवल खुद को जानता है, बाहरी डेटा पर निर्भर नहीं करता है;
एक्स्टेंसिबिलिटी - कंस्ट्रक्टर को फिर से परिभाषित या वंशजों में जोड़ा जा सकता है;

Minuses की:

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

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

"सार कारखाना"

कुछ वर्ग के साथी। यह विशिष्ट हो सकता है, या "गठबंधन" कर सकता है। स्थिर हो सकता है (कोई उदाहरण नहीं)। "संयोजन" का एक उदाहरण एक विन्यास वर्ग हो सकता है। यह फैकेड के पीछे भी छिपा हो सकता है।

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

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

पेशेवरों से:

वंशजों में अच्छा पुनर्वितरण
सरलीकृत कॉल
कारखाने के आधार पर, प्रतिस्थापन (राज्य टेम्पलेट) को लागू करना आसान है

लेकिन इसके नुकसान भी हैं:

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

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

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

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

फैक्टरी विधि

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

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

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

पेशेवरों से:

टेम्प्लेट टेम्पलेट विधि से मिलान करना आसान होगा
हमें संक्षिप्त कोड मिलता है जिसमें तर्क स्पष्ट रूप से दिखाई देता है (इसे तरीकों और मापदंडों के ढेर के बीच देखने की जरूरत नहीं है)

अनिवार्य रूप से कोई विपक्ष नहीं हैं।

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

छोटा उदाहरण

हार्ड ड्राइव पर फ़ाइल में लॉग इन करने के लिए हमारे पास एक वर्ग है। यह है कि "कहां?" पैटर्न के भीतर सामान्य तरीके कैसे दिख सकते हैं:

प्रोटोटाइप:

constructor Create(aFilename: string; aLogLevel: TLogLevel);

वह सब जो डिजाइनर को पता होना चाहिए, उसे मापदंडों के रूप में पारित किया गया है।

कारखाना:

 function GetLogger(aLogLevel: TLogLevel): ILogger;

फ़ैक्टरी को पता है कि कौन सी फाइल को लिखना है, जैसा कि एप्लिकेशन सेटिंग्स में निर्दिष्ट है।

फैक्टरी विधि:

 function NewLogger: ILogger;

क्लाइंट वर्ग में, यह पता करने के लिए कि किस विस्तार से लॉग करना है।

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

डेटाबेस में प्रवेश करने के लिए, फैक्ट्री के वंशज में गेटलॉगर विधि को ओवरराइड करना पर्याप्त है।

थोड़ा जेनेरिक डिज़ाइन पैटर्न के बारे में