जनरेटिव्ह नमुने

३.१ सिंगलटन

सिंगलटन हा एक सामान्य डिझाइन पॅटर्न आहे जो हमी देतो की सिंगल-थ्रेडेड ऍप्लिकेशनमध्ये काही वर्गाचा एकच प्रसंग असेल आणि या उदाहरणासाठी जागतिक प्रवेश बिंदू प्रदान करतो.

बर्‍याचदा, नवशिक्या प्रोग्रॅमर्सना काही स्टॅटिक क्लासमध्ये युटिलिटी पद्धती एकत्र करायला आवडतात - एक वर्ग ज्यामध्ये फक्त स्टॅटिक पद्धती असतात. या दृष्टिकोनाचे अनेक तोटे आहेत - उदाहरणार्थ, आपण अशा वर्गाच्या ऑब्जेक्टचा संदर्भ पास करू शकत नाही, अशा पद्धतींची चाचणी घेणे कठीण आहे आणि यासारखे.

पर्याय म्हणून, सिंगलटन क्लास सोल्यूशन प्रस्तावित केले गेले: एक वर्ग ज्यामध्ये फक्त एक ऑब्जेक्ट असू शकतो. हा ऑब्जेक्ट तयार करण्याचा प्रयत्न करताना, तो आधीपासून अस्तित्वात नसल्यासच तयार केला जातो, अन्यथा आधीपासून अस्तित्वात असलेल्या उदाहरणाचा संदर्भ परत केला जातो.

हे आवश्यक आहे की वर्गाचे उदाहरण वापरणे शक्य आहे, कारण बर्‍याच प्रकरणांमध्ये विस्तृत कार्यक्षमता उपलब्ध होते. उदाहरणार्थ, हा वर्ग काही इंटरफेस अंमलात आणू शकतो आणि त्याचा ऑब्जेक्ट इंटरफेसची अंमलबजावणी म्हणून इतर पद्धतींमध्ये पास केला जाऊ शकतो. स्थिर पद्धतींच्या संचासह काय केले जाऊ शकत नाही.

साधक:

• पद्धती ऑब्जेक्टशी बांधील आहेत, स्थिर वर्ग नाही - आपण संदर्भानुसार ऑब्जेक्ट पास करू शकता.
• ऑब्जेक्ट पद्धती तपासणे आणि उपहास करणे खूप सोपे आहे.
• एखादी वस्तू जेव्हा आवश्यक असेल तेव्हाच तयार केली जाते: आळशी ऑब्जेक्ट आरंभीकरण.
• प्रक्षेपणासाठी आवश्यक नसलेले अनेक एकेरी असल्यास कार्यक्रमाच्या प्रारंभिक प्रक्षेपणास गती देणे.
• एकट्याचे पुढे टेम्प्लेट-स्ट्रॅटेजी किंवा अशा अनेक वस्तूंमध्ये रूपांतर केले जाऊ शकते.

उणे:

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

३.२ कारखाना [पद्धत]

फॅक्टरी पद्धत ही एक सामान्य डिझाइन नमुना आहे जी विशिष्ट वर्गाची उदाहरणे तयार करण्यासाठी इंटरफेससह उपवर्ग (वर्ग-वारसा) प्रदान करते. निर्मितीच्या वेळी, कोणता वर्ग तयार करायचा हे वंशज ठरवू शकतात.

दुसऱ्या शब्दांत, हे टेम्पलेट मूळ वर्गाच्या वंशजांना ऑब्जेक्ट्सची निर्मिती सोपवते. हे तुम्हाला प्रोग्राम कोडमध्ये ठोस वर्ग वापरण्याची परवानगी देत ​​​​नाही, परंतु उच्च स्तरावर अमूर्त वस्तू हाताळण्यासाठी.

हा पॅटर्न ऑब्जेक्ट तयार करण्यासाठी इंटरफेस परिभाषित करतो, परंतु ऑब्जेक्ट कोणत्या वर्गावर आधारित आहे हे ठरवण्यासाठी ते उपवर्गांवर सोडते. फॅक्टरी पद्धत वर्गाला उपवर्ग तयार करण्याची परवानगी देते. जेव्हा वापरले जाते:

• वर्गाला कोणते उपवर्ग तयार करायचे आहेत हे आधीच माहित नसते.
• वर्गाची रचना केली जाते जेणेकरून ते तयार केलेल्या वस्तू उपवर्गांद्वारे निर्दिष्ट केल्या जातात.
• वर्ग त्याच्या जबाबदाऱ्या अनेक मदतनीस उपवर्गांपैकी एकाला सोपवतो आणि कोणता वर्ग या जबाबदाऱ्या स्वीकारतो हे ठरवण्यासाठी नियोजन केले जाते.

3.3 अमूर्त कारखाना

अ‍ॅबस्ट्रॅक्ट फॅक्टरी हा एक सामान्य डिझाइन पॅटर्न आहे जो संबंधित किंवा परस्परावलंबी वस्तूंचे कंक्रीट वर्ग निर्दिष्ट न करता कुटुंबे तयार करण्यासाठी इंटरफेस प्रदान करतो.

नमुना एक अमूर्त वर्ग फॅक्टरी तयार करून लागू केला जातो, जो सिस्टम घटक तयार करण्यासाठी एक इंटरफेस आहे (उदाहरणार्थ, विंडो इंटरफेससाठी, ते विंडो आणि बटणे तयार करू शकते). मग वर्ग लिहिले जातात जे या इंटरफेसची अंमलबजावणी करतात.

हे अशा प्रकरणांमध्ये वापरले जाते जेव्हा प्रोग्राम प्रक्रिया आणि नवीन वस्तूंच्या प्रकारांपासून स्वतंत्र असणे आवश्यक आहे. जेव्हा संबंधित वस्तूंचे कुटुंबे किंवा गट तयार करणे आवश्यक असते, त्याच संदर्भात यातील भिन्न संचांमधून एकाच वेळी वापरण्याची शक्यता वगळून.

सामर्थ्य:

• विशिष्ट वर्गांना वेगळे करते;
• उत्पादन कुटुंबांची पुनर्स्थापना सुलभ करते;
• उत्पादनाच्या सुसंगततेची हमी देते.

समजा तुमचा प्रोग्राम फाईल सिस्टीमसह कार्य करतो. त्यानंतर लिनक्समध्ये काम करण्यासाठी तुम्हाला LinuxFile, LinuxDirectory, LinuxFileSystem ऑब्जेक्ट्सची आवश्यकता आहे. आणि Windwos मध्ये काम करण्यासाठी, तुम्हाला WindowsFile, WindowsDirectory, WindowsFileSystem वर्गांची आवश्यकता आहे.

पाथ क्लास, जो Path.of() द्वारे तयार केला जातो, ही अशीच एक केस आहे. पथ खरोखर एक वर्ग नाही, परंतु एक इंटरफेस आहे आणि त्यात WindowsPath आणि LinuxPath अंमलबजावणी आहेत. आणि कोणत्या प्रकारची ऑब्जेक्ट तयार केली जाईल हे तुमच्या कोडपासून लपवलेले आहे आणि रनटाइमवर ठरवले जाईल.

3.4 प्रोटोटाइप

प्रोटोटाइप एक जनरेटिव्ह डिझाइन नमुना आहे.

हा नमुना प्रोटोटाइप उदाहरण वापरून तयार केलेल्या ऑब्जेक्ट्सचे प्रकार परिभाषित करतो आणि या प्रोटोटाइपची कॉपी करून नवीन ऑब्जेक्ट्स तयार करतो. हे आपल्याला अंमलबजावणीपासून दूर जाण्याची आणि "इंटरफेसद्वारे प्रोग्रामिंग" च्या तत्त्वाचे अनुसरण करण्यास अनुमती देते.

पदानुक्रमाच्या शीर्षस्थानी एक इंटरफेस/अमूर्त वर्ग हा परत येणारा प्रकार म्हणून निर्दिष्ट केला आहे आणि वंशज वर्ग हा प्रकार लागू करणारा वारस बदलू शकतो. सोप्या भाषेत सांगायचे तर एखादी वस्तू कन्स्ट्रक्टरद्वारे तयार करण्याऐवजी दुसरी वस्तू क्लोन करून तयार करण्याचा हा प्रकार आहे.

नमुना यासाठी वापरला जातो:

• एक मानक मार्गाने ऑब्जेक्ट तयार करण्याचा अतिरिक्त प्रयत्न टाळणे (म्हणजे कन्स्ट्रक्टर वापरणे, कारण या प्रकरणात संपूर्ण ऑब्जेक्टच्या पूर्वज पदानुक्रमाचे कन्स्ट्रक्टर देखील म्हटले जाईल), जेव्हा हे अनुप्रयोगासाठी प्रतिबंधितपणे महाग असते.
• क्लायंट ऍप्लिकेशनमध्ये ऑब्जेक्ट क्रिएटरला इनहेरिट करणे टाळा, जसे अमूर्त फॅक्टरी पॅटर्न करते.

तुमचा प्रोग्राम उत्पादने कशी तयार करतो, तयार करतो आणि सादर करतो याकडे लक्ष देत नाही तेव्हा या डिझाइन पॅटर्नचा वापर करा:

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