सिंगलटन पैटर्न के विकल्प

Question

मैंने सिंगलटन पैटर्न के बारे में अलग-अलग राय पढ़ी है। कुछ लोग यह कहते हैं कि इसे हर कीमत पर और अन्य लोगों से बचना चाहिए कि यह कुछ स्थितियों में उपयोगी हो सकता है।

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

F& f                   = F::instance();
boost::shared_ptr<A> a = f.createA();

तो मेरा परिदृश्य सामान्य है

1. मुझे या तो ऑप्टिमाइज़ेशन कारणों के लिए एक वर्ग की केवल एक आवृत्ति की आवश्यकता है (मुझे कई फैक्ट्री ऑब्जेक्ट्स की आवश्यकता नहीं है) या सामान्य स्थिति साझा करने के लिए (जैसे कि फैक्ट्री जानता है कि ए के कितने उदाहरण अभी भी बना सकते हैं)
2. मुझे कोड के विभिन्न स्थानों में एफ के इस उदाहरण तक पहुंच के लिए एक रास्ता चाहिए।

मुझे इस चर्चा में कोई दिलचस्पी नहीं है कि यह पैटर्न अच्छा है या बुरा है, लेकिन यह मानकर कि मैं एक सिंगलटन का उपयोग करने से बचना चाहता हूं, मैं अन्य कौन से पैटर्न का उपयोग कर सकता हूं?

कार्यक्रम के दौरान किसी बिंदु पर कारखाना बनाने के लिए रजिस्ट्री (या 2) से फैक्ट्री ऑब्जेक्ट प्राप्त करने के लिए मेरे पास जो विचार थे (1) थे और फिर एक पैरामीटर के रूप में फैक्ट्री को पास करें।

समाधान (1) में, रजिस्ट्री स्वयं एक सिंगलटन है, इसलिए मैंने कारखाने से रजिस्ट्री तक एक सिंगलटन का उपयोग नहीं करने की समस्या को स्थानांतरित कर दिया है।

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

क्या यह अंतिम विकल्प होगा (एक प्रारंभिक सिंगलटन का उपयोग करना जो अन्य सभी अनूठी वस्तुओं को बनाता है और सही स्थानों पर अन्य सभी सिंग्लेटों को इंजेक्ट करता है) एक स्वीकार्य समाधान है? क्या यह वह समाधान है, जो एकांत में सुझाया जाता है, जब कोई एकल का उपयोग नहीं करने की सलाह देता है, या अन्य समाधान क्या हैं, जैसे ऊपर वर्णित उदाहरण में?

संपादित करें

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

चीजों को स्पष्ट करने के लिए (a) और (b) के लिए सिंगलटन पैटर्न के लिए अद्वितीय शब्द का उपयोग करें । तो, मुझे पता है कि सिंगलटन पैटर्न और निर्भरता इंजेक्शन क्या हैं (बीटीडब्लू, हाल ही में मैं कुछ कोड मैं काम कर रहा हूं) से सिंगलटन पैटर्न के उदाहरणों को हटाने के लिए डीआई का भारी उपयोग कर रहा हूं।

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

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

Comments

निर्भरता इंजेक्शन ...

— फाल्कन

@ फाल्कन: डिपेंडेंसी इंजेक्शन ... क्या? DI इस समस्या को हल करने के लिए कुछ नहीं करता है, हालांकि यह अक्सर आपको इसे छिपाने का एक आसान तरीका देता है।

— पीडीआर

@ फाल्कन आप आईओसी कंटेनर मतलब है? यह आपको एक पंक्ति में निर्भरता को हल करने की अनुमति देगा। उदाहरण के लिए निर्भरता। समाधान <IFoo> (); या निर्भरता।

— 20

यह एक बहुत पुराना प्रश्न है, और पहले से ही उत्तर दिया गया है। मैं अभी भी यह एक लिंक करने के लिए अच्छा होगा हालांकि: stackoverflow.com/questions/162042/…

— TheSilverBullet

संबंधित (संभवतः एक डुप्लिकेट): एक एकल वर्ग के लिए क्या विकल्प हैं जो केवल एक उदाहरण हो सकते हैं?

— gnat

Answer 1

आपका दूसरा विकल्प जाने का एक अच्छा तरीका है - यह एक प्रकार की निर्भरता इंजेक्शन है, जो कि आपके कार्यक्रम के दौरान राज्य को साझा करने के लिए उपयोग किया जाने वाला पैटर्न है, जब आप एकल और वैश्विक चर से बचना चाहते हैं।

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

Answer 2

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

सिंगलटन के बजाय, मैं इनमें से किसी एक का उपयोग करना पसंद करता हूं:

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

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

Comments

यह एक बहुत अच्छा जवाब है लेकिन मैं वास्तव में यह नहीं पूछ रहा था कि मुझे सिंगलटन पैटर्न का उपयोग क्यों करना चाहिए / नहीं करना चाहिए। मुझे पता है कि वैश्विक राज्य के साथ जो परेशानी हो सकती है। वैसे भी, सवाल का विषय यह था कि अद्वितीय वस्तुओं और अभी तक एक सिंगलटन-पैटर्न मुक्त कार्यान्वयन कैसे किया गया था।

— जियोर्जियो

Answer 3

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

GoF पुस्तक में, स्थिर फैक्ट्री विधि जो एक स्थिर क्षेत्र का संदर्भ देती है, केवल एक उदाहरण था कि यह तंत्र कैसा दिख सकता है, और एक गंभीर कमियां है। दुर्भाग्य से, हर कोई और उनके कुत्ते ने उस तंत्र पर कब्जा कर लिया और सोचा कि यह सिंगलटन क्या है।

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

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

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

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

Comments

क्या आपका मतलब यह है कि मूल विचार निर्भरता इंजेक्शन मूल रूप से पहला दृष्टिकोण है जो मैंने ऊपर स्केच किया था (जैसे रजिस्ट्री का उपयोग करके), मूल विचार पर?

— जियोर्जियो

@ जिओर्जियो: DI में हमेशा ऐसी रजिस्ट्री शामिल होती है, लेकिन मुख्य बिंदु जो इसे बेहतर बनाता है वह यह है कि रजिस्ट्री को क्वेरी करने के बजाय जहां भी आपको किसी ऑब्जेक्ट की आवश्यकता होती है, आपके पास केंद्रीय वस्तुएं होती हैं जो कि ट्रांज़िटली पॉप्युलेट होती हैं, जैसा कि मैंने ऊपर लिखा था।

— माइकल बोर्गवर्ड

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

— माइकल बोर्गवर्ड

कुछ लोग (आप सहित) ध्यान से प्रश्न नहीं पढ़ते हैं और गलतफहमी होती है कि वास्तव में क्या पूछा जा रहा है।

— जियोर्जियो

@ जियोर्जियो: आपके मूल प्रश्न में कुछ भी नहीं दर्शाया गया है कि आप पहले से निर्भरता इंजेक्शन से परिचित हैं। और अद्यतन उत्तर देखें।

— माइकल बोर्गवर्ड 19

Answer 4

कुछ विकल्प हैं:

निर्भरता अन्तःक्षेपण

प्रत्येक वस्तु की अपनी निर्भरता उस पर बीतती है जब इसे बनाया गया था। आमतौर पर या तो एक ढांचा या कम संख्या में फैक्ट्री कक्षाएं वस्तुओं को बनाने और वायरिंग के लिए जिम्मेदार होती हैं

सेवा रजिस्ट्री

प्रत्येक ऑब्जेक्ट को सेवा रजिस्ट्री ऑब्जेक्ट पास किया जाता है। यह विभिन्न वस्तुओं को अनुरोध करने के तरीके प्रदान करता है जो विभिन्न सेवाएं प्रदान करते हैं। एंड्रॉइड फ्रेमवर्क इस पैटर्न का उपयोग करता है

रूट मैनेजर

एक एकल ऑब्जेक्ट है जो ऑब्जेक्ट ग्राफ का मूल है। इस ऑब्जेक्ट से लिंक का अनुसरण करके किसी अन्य ऑब्जेक्ट को अंततः पाया जा सकता है। कोड जैसा दिखता है:

GetSomeManager()->GetRootManager()->GetAnotherManager()->DoActualThingICareAbout()

Comments

मॉकिंग के अलावा, किस लाभ का DI के पास एक सिंगलटन का उपयोग करने से अधिक है? यह एक ऐसा प्रश्न है, जिसने मुझे बहुत लंबे समय के लिए खतरे में डाल दिया है। रजिस्ट्री और रूट मैनेजर के रूप में, वे या तो एक सिंगलटन के रूप में या DI के माध्यम से लागू नहीं होते हैं? (वास्तव में आईओसी कंटेनर है एक रजिस्ट्री, है ना?)

— कोनराड रूडोल्फ

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

— विंस्टन एवर्ट

@KonradRudolph, क्या अन्य तरीके सिंगलटन या DI का उपयोग कर लागू किए गए हैं? हां और नहीं। अंत में, आप या तो वस्तुओं को वैश्विक राज्य में पास या स्टोर करने के लिए मिल गए हैं। लेकिन आप यह कैसे करते हैं, इसमें सूक्ष्म अंतर हैं। उपरोक्त तीन संस्करण वैश्विक स्थिति का उपयोग करने से बचते हैं; लेकिन जिस तरह से अंत-कोड को संदर्भ मिलता है वह अलग है।

— विंस्टन एवर्ट

यदि एकल Singleton::instanceग्राहक कोड में हर जगह क्वेरी करने के बजाय सिंगलटन किसी इंटरफ़ेस को लागू करता है (या भले ही नहीं) और सिंगलटन के तरीकों को पास करने के लिए एकल ऑब्जेक्ट का उपयोग नहीं करता है ।

— कोनराड रुडोल्फ

@KonradRudolph, तो आप वास्तव में कुछ हाइब्रिड सिंगलटन / DI दृष्टिकोण का उपयोग कर रहे हैं। मेरा विशुद्ध पक्ष सोचता है कि आपको शुद्ध DI दृष्टिकोण के लिए जाना चाहिए। हालांकि, सिंगलटन के अधिकांश मुद्दे वास्तव में वहां लागू नहीं होते हैं।

— विंस्टन एवर्ट

Answer 5

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

class Factory
{
public:
    static Object* createObject(...);
};

Object* obj = Factory::createObject(...);

बेशक, यह तब टूट जाता है जब सिंगलटन के संचालन को एक फ़ंक्शन कॉल तक कम नहीं किया जा सकता है, हालांकि शायद संबंधित कार्यों का एक छोटा सा सेट आपको मिल सकता है।

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

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

Comments

व्यक्तिगत रूप से मैं इसे सिंगलटन पैटर्न के सिर्फ एक अलग कार्यान्वयन के रूप में देखता हूं। इस मामले में एकल वर्ग उदाहरण ही वर्ग है। विशेष रूप से: इसमें "वास्तविक" सिंगलटन के समान सभी कमियां हैं।

— जोकिम सॉयर

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

— जियोर्जियो

Answer 6

यदि आप C ++ या पाइथन की तरह एक बहुभाषी भाषा का उपयोग कर रहे हैं, तो एकल वर्ग के लिए एक विकल्प एक नाम स्थान में लिपटे फ़ंक्शन / चर का एक सेट है।

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

यह केवल टूट जाता है यदि आप विरासत चाहते हैं। मैंने बहुत सारे सिंगलेट्स देखे हैं जो इस तरह से बेहतर होते।

Answer 7

सिंगलेट्स एनकैप्सुलेशन

केस दृश्य। आपका एप्लिकेशन ऑब्जेक्ट ओरिएंटेड है, और आपके पास 3 या 4 विशिष्ट सिंग्लेटनों की आवश्यकता है, भले ही आपके पास अधिक कक्षाएं हों।

उदाहरण से पहले (सी ++ स्यूडोकोड की तरह):

// network info
class Session {
  // ...
};

// current user connection info
class CurrentUser {
  // ...
};

// configuration upon user
class UserConfiguration {
  // ...
};

// configuration upon P.C.,
// example: monitor resolution
class TerminalConfiguration {
  // ...
};

एक तरीका यह है कि कुछ (वैश्विक) सिंगलनेट्स को आंशिक रूप से हटा दिया जाए, उन सभी को एक अद्वितीय सिंगलटन में इनकैप्सुलेट करके, जिसमें सदस्यों के रूप में, अन्य सिंगलटन हैं।

इस तरह, "कई सिंगलटन, एप्रोच, बनाम, बिल्कुल नहीं सिंगलटन, एप्रोच" के बजाय, हमारे पास "सभी सिंग्लेटन्स को एक, दृष्टिकोण" में बदलना है।

उदाहरण के बाद (सी ++ स्यूडोकोड की तरह):

// network info
class NetworkInfoClass {
  // ...
};

// current user connection info
class CurrentUserClass {
  // ...
};

// configuration upon user
// favorite options menues
class UserConfigurationClass {
  // ...
};

// configuration upon P.C.,
// example: monitor resolution
class TerminalConfigurationClass {
  // ...
};

// this class is instantiated as a singleton
class SessionClass {
  public: NetworkInfoClass NetworkInfo;
  public: CurrentUserClass CurrentUser;
  public: UserConfigurationClass UserConfiguration;
  public: TerminalConfigurationClass TerminalConfiguration;

  public: static SessionClass Instance();
};

कृपया ध्यान दें, कि उदाहरण छद्मकोड की तरह अधिक हैं, और मामूली कीड़े, या वाक्यविन्यास त्रुटियों को अनदेखा करते हैं, और प्रश्न के समाधान पर विचार करते हैं।

विचार करने के लिए अन्य चीज भी है, क्योंकि, उपयोग की जाने वाली प्रोग्रामिंग भाषा, आपके सिंगलटन या गैर सिंगलटन कार्यान्वयन को कैसे प्रभावित कर सकती है।

चीयर्स।

Answer 8

आपकी मूल आवश्यकताएं:

तो मेरा परिदृश्य सामान्य है

1. मुझे अनुकूलन कारणों से या तो कक्षा के केवल एक उदाहरण की आवश्यकता है (मुझे कई फैक्ट्री ऑब्जेक्ट्स की आवश्यकता नहीं है) या कॉमन स्टेट शेयर करने के लिए (जैसे कि फैक्ट्री को पता है कि A के कितने उदाहरण अभी भी बना सकते हैं)
2. मुझे कोड के विभिन्न स्थानों में एफ के इस उदाहरण तक पहुंच के लिए एक रास्ता चाहिए।

एक सिंगलटन की परिभाषा के साथ लाइन न करें (और जो आप बाद में देखें)। GoF से (मेरा संस्करण 1995 है) पृष्ठ 127:

सुनिश्चित करें कि एक वर्ग के पास केवल एक ही उदाहरण है, और उसे वैश्विक पहुंच प्रदान करें।

यदि आपको केवल एक उदाहरण की आवश्यकता है, तो यह आपको अधिक बनाने से रोकता नहीं है ।

यदि आप एकल, विश्व स्तर पर सुलभ उदाहरण चाहते हैं तो विश्व स्तर पर सुलभ उदाहरण बनाएं । आपको जो कुछ भी करना है उसके लिए एक पैटर्न नाम रखने की आवश्यकता नहीं है। और हाँ, विश्व स्तर पर एकल सुलभ उदाहरण आमतौर पर खराब होते हैं। उन्हें एक नाम देना उन्हें कम बुरा नहीं बनाता है ।

वैश्विक पहुंच से बचने के लिए, आम 'एक उदाहरण बनाते हैं और इसे पास करते हैं' या 'दो वस्तुओं का स्वामी उन्हें एक साथ गोंद देता है' दृष्टिकोण अच्छी तरह से काम करता है।

Answer 9

IoC कंटेनर का उपयोग कैसे करें? कुछ विचार के साथ आप कुछ की तर्ज पर समाप्त कर सकते हैं:

Dependency.Resolve<IFoo>(); 

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

स्थैतिक सिंगलटन शून्य विधि को इसके साथ प्रतिस्थापित किया जा सकता है:

Dependency.Resolve<IFoo>().DoSomething();

स्थैतिक सिंगलटन गेटर विधि को इसके साथ बदला जा सकता है:

var result = Dependency.Resolve<IFoo>().GetFoo();

उदाहरण .NET के लिए प्रासंगिक है, लेकिन मैं निश्चित हूं कि अन्य भाषाओं में भी बहुत कुछ इसी तरह हासिल किया जा सकता है।