जनरेटिव पैटर्न

3.1 सिंगलटन

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

बहुत बार, नौसिखिए प्रोग्रामर उपयोगिता विधियों को कुछ स्थिर वर्ग में इकट्ठा करना पसंद करते हैं - एक ऐसा वर्ग जिसमें केवल स्थैतिक विधियाँ होती हैं। इस दृष्टिकोण के कई नुकसान हैं - उदाहरण के लिए, आप इस तरह के वर्ग की किसी वस्तु का संदर्भ नहीं दे सकते हैं, ऐसे तरीकों का परीक्षण करना मुश्किल है, और इसी तरह।

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

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

पेशेवरों:

• विधियाँ किसी वस्तु से बंधी होती हैं, स्थिर वर्ग से नहीं - आप किसी वस्तु को संदर्भ द्वारा पारित कर सकते हैं।
• ऑब्जेक्ट विधियों का परीक्षण और नकल करना बहुत आसान है।
• एक वस्तु केवल तभी बनाई जाती है जब आवश्यक हो: आलसी वस्तु आरंभीकरण।
• कार्यक्रम के प्रारंभिक लॉन्च में तेजी लाना यदि कई एकल हैं जो लॉन्च के लिए आवश्यक नहीं हैं।
• अकेले ही आगे एक टेम्पलेट-रणनीति या ऐसी कई वस्तुओं में बदल दिया जा सकता है।

विपक्ष:

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

3.2 कारखाना [विधि]

एक फ़ैक्टरी विधि एक सामान्य डिज़ाइन पैटर्न है जो एक निश्चित वर्ग के उदाहरण बनाने के लिए एक इंटरफ़ेस के साथ उपवर्ग (वर्ग-इनहेरिटर्स) प्रदान करता है। निर्माण के समय, वंशज यह निर्धारित कर सकते हैं कि किस वर्ग को बनाना है।

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

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

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

3.3 सार कारखाना

एक अमूर्त फैक्ट्री एक सामान्य डिज़ाइन पैटर्न है जो संबंधित या अन्योन्याश्रित वस्तुओं के परिवारों को उनके ठोस वर्गों को निर्दिष्ट किए बिना बनाने के लिए एक इंटरफ़ेस प्रदान करता है।

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

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

ताकत:

• विशिष्ट वर्गों को अलग करता है;
• उत्पाद परिवारों के प्रतिस्थापन को सरल करता है;
• उत्पाद संगतता की गारंटी देता है।

मान लीजिए कि आपका प्रोग्राम फाइल सिस्टम के साथ काम करता है। फिर लिनक्स में काम करने के लिए आपको LinuxFile, LinuxDirectory, LinuxFileSystem ऑब्जेक्ट्स की आवश्यकता होती है। और Windwos में काम करने के लिए, आपको WindowsFile, WindowsDirectory, WindowsFileSystem क्लासेस की आवश्यकता है।

Path.of() के माध्यम से बनाई गई पाथ क्लास, ऐसा ही एक मामला है। पथ वास्तव में एक वर्ग नहीं है, बल्कि एक इंटरफ़ेस है, और इसमें WindowsPath और LinuxPath कार्यान्वयन हैं। और किस प्रकार का ऑब्जेक्ट बनाया जाएगा यह आपके कोड से छिपा हुआ है और रनटाइम पर तय किया जाएगा।

3.4 प्रोटोटाइप

प्रोटोटाइप एक जनरेटिव डिज़ाइन पैटर्न है।

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

पदानुक्रम के शीर्ष पर एक इंटरफ़ेस / अमूर्त वर्ग को रिटर्निंग प्रकार के रूप में निर्दिष्ट किया गया है, और वंशज वर्ग एक वारिस को स्थानापन्न कर सकते हैं जो इस प्रकार को लागू करता है। सीधे शब्दों में कहें, यह एक कंस्ट्रक्टर के माध्यम से बनाने के बजाय किसी अन्य ऑब्जेक्ट को क्लोन करके ऑब्जेक्ट बनाने का पैटर्न है।

पैटर्न का उपयोग इसके लिए किया जाता है:

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

इस डिज़ाइन पैटर्न का उपयोग तब करें जब आपका प्रोग्राम इस बात की परवाह नहीं करता है कि यह उत्पादों को कैसे बनाता है, बनाता है और प्रस्तुत करता है:

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