मेरे पास एक ऐसा एप्लिकेशन है जिसमें एप्लिकेशन-व्यापी सेटिंग्स (संसाधनों के स्थान, उपयोगकर्ता सेटिंग्स और ऐसे) को संग्रहीत करने के लिए कई कक्षाएं उपयोग की जाती हैं। अभी ये वर्ग स्थिर क्षेत्रों और विधियों से भरे हुए हैं, लेकिन मैं उन्हें कभी भी तत्काल नहीं करता हूं।सिंगलेट्स के लिए अच्छा मामला?
किसी ने सुझाव दिया कि मैं उन्हें सिंगलेट्स बनाउंगा, इसके लिए क्या मामला है?
प्रभावी जावा का कहना है:
Singletons typically represent some system component that is intrinsically
unique, such as a video display or file system.
तो अपने घटक वारंट एक उदाहरण पूरा आवेदन और यह कुछ राज्य यह समझदारी की बात है कि यह एक सिंगलटन
बनाने के लिए बनाता है पर समन्वयित यदि आपका मामला, आवेदन की सेटिंग्स सिंगलटन के लिए एक अच्छा उम्मीदवार है।
दूसरी तरफ, एक वर्ग में केवल स्थिर विधियां हो सकती हैं यदि आप कुछ कार्यों को एक साथ समूहबद्ध करना चाहते हैं, जैसे यूटिलिटी क्लासेस, जेडीके में उदाहरण java.util.Arays java.util.Collections हैं। इनमें कई संबंधित विधियां हैं जो सरणी या संग्रह पर कार्य करती हैं
यह एक स्थिर वर्ग पर लाभ कैसे प्रदान करता है? – Borealid
@ बोरीलिड आप कक्षा के निर्माण/विनाश पर नियंत्रण प्राप्त करते हैं, जो राज्य को बनाए रखने के लिए महत्वपूर्ण हो सकता है। स्टेटिक कक्षाएं उपयोगिता वर्गों की तरह स्टेटलेस होनी चाहिए। – Jake
@ बोरीलिड ज्यादातर मामलों में लाभ पठनीयता और ओओ लालित्य है। एक वर्ग का एक उदाहरण वास्तविक प्रारंभिक स्थिति का प्रतिनिधित्व करता है। जहां स्थिर तरीके और फ़ील्ड अधिक समझ में आते हैं जहां आप कुछ कार्यों को एक साथ समूहबद्ध करना चाहते हैं और आप उन्हें किसी विशेष उदाहरण या प्रकार के लिए नहीं रख सकते हैं। मेरे अपडेट किए गए उत्तर – naikus
यदि आपको कभी भी उन्हें तुरंत चालू करने की आवश्यकता नहीं है, तो मुझे सिंगलेट्स का बिंदु नहीं दिखाई देता है। खैर, मुझे यह संशोधित करना चाहिए कि - यदि इन कक्षाओं को तत्काल नहीं किया जा सकता है, तो उन्हें सिंगलेट्स की तुलना करने की समझ में नहीं आता है - सिंगलटन पैटर्न एक ऑब्जेक्ट को तत्कालता को प्रतिबंधित करता है, और उस चीज की तुलना जिसे तत्काल नहीं किया जा सकता है, सही बात।
मुझे लगता है कि सिंगलेट्स का मेरा मुख्य उपयोग आम तौर पर एक वर्ग शामिल करता है जिसमें स्थैतिक विधियां होती हैं, जो कि पर्यावरण की तैयारी के बाद, स्वयं का एक उदाहरण तत्काल कर सकती हैं। CloneNotSupportedException फेंकने के लिए निजी रचनाकारों का उपयोग करके Object.clone() ओवरराइड करके, कोई अन्य वर्ग इसका एक नया उदाहरण नहीं बना सकता है, या यदि वे कभी भी इसका उदाहरण पारित कर चुके हैं, तो वे इसे क्लोन नहीं कर सकते हैं।
मुझे लगता है कि मैं कहूंगा कि यदि आपकी एप्लिकेशन सेटिंग्स ऐसी कक्षा का हिस्सा हैं जो कभी भी तत्काल नहीं होती है, तो यह कहना प्रासंगिक नहीं है कि "यह सिंगलटन होना चाहिए/नहीं होना चाहिए।"
वास्तव में जावा में सिंगलेट्स करने का वास्तव में एक अच्छा तरीका है जिसे 'ऑब्जेक्ट.क्लोन()' ओवरराइड करने की आवश्यकता नहीं है, जिसमें एक निजी आंतरिक वर्ग में सिंगलटन वर्ग का उदाहरण होता है। जब आप 'getInstance()' विधि को कॉल करते हैं, तो आप इसे आंतरिक आवृत्ति पर इंगित करते हैं। – JBirch
सिंगलटन आप किसी ऑब्जेक्ट संदर्भ दे देंगे, कि आप सभी अपने अनुप्रयोग से अधिक उपयोग कर सकते हैं ... अगर आप वस्तुओं और/या बहुरूपता चाहते आप सिंगलटन का उपयोग करेगा ...
ऑब्जेक्ट संदर्भ होने के बाद आप अपने पूरे ऐप का उपयोग कर सकते हैं, यह एक अच्छी बात नहीं है। पूर्व-ऑब्जेक्ट उन्मुख दिनों में हमने उन "वैश्विक चर" को बुलाया और उन्होंने रखरखाव को बहुत मुश्किल बना दिया। – DJClayworth
मैं तुम्हें बनाने की आवश्यकता लगता है सिग्लेटन वर्ग। बस इस कक्षा के निर्माता को निजी बनाएं। जावा में गणित वर्ग की तरह।
public final class Math {
/**
* Don't let anyone instantiate this class.
*/
private Math() {}
//static fields and methods
}
यह एक सिंगलटन वर्ग नहीं है बल्कि एक अमूर्त वर्ग का उपयोग है (जिसे intantiated नहीं किया जा सकता है)। एक सिंगलटन कक्षा को तुरंत एक बार तुरंत चालू किया जाता है और एक स्थिर उदाहरण गेटटर होता है। – f1sh
हाँ मुझे पता है कि सिंगलटन क्लास क्या है। वह पूछ रही है कि उसे सिंगलटन के लिए जाना चाहिए और मैं कह रहा हूं कि सिंगलटन के लिए जाने की कोई ज़रूरत नहीं है। लेकिन आपको अपने वर्ग के कन्स्ट्रक्टर को आकस्मिक कक्षा के तत्काल के लिए निजी बनाना चाहिए। – Vivart
विवार्ट, ऐसे मामले हैं जहां सिंगलटन उपयोगी है। मेरा जवाब देखें – DJClayworth
Singletons अक्सर स्थितियों में दिखाने की तरह आप describing- आप कुछ जगह में रहने की जरूरत है कि वैश्विक डेटा न किसी तरह का कर रहे हैं, और यदि आप कभी भी एक ही की आवश्यकता होगी, खासकर आपको लगता है कि यह सुनिश्चित करना चाहते आप केवल एक ही कर सकते हैं।
सरल बात आप कर सकते हैं एक स्थिर चर रहा है:
public class Globals{
public static final int ACONSTANT=1;
यह ठीक है, और यह सुनिश्चित करता है कि आप केवल एक ही होगा, और आप कोई इन्स्टेन्शियशन मुद्दे हैं। मुख्य नकारात्मक, ज़ाहिर है कि यह आपके डेटा को बेक करने में अक्सर असुविधाजनक होता है।यह लोडिंग समस्या में भी चलता है यदि उदाहरण के लिए, आपकी स्ट्रिंग वास्तव में बाहरी संसाधन से कुछ बनाकर बनाई गई है, (प्राइमेटिव्स के साथ एक गॉचा भी है - यदि आपका स्थिर अंतिम एक int है, कहें, कक्षाएं जो उस पर निर्भर करती हैं यह इनलाइन संकलन, जिसका अर्थ है कि आपके स्थिरांक recompiling अनुप्रयोग में स्थिरांक की जगह नहीं कर सकते हैं - जैसे, public class B{ int i = Globals.ACONSTANT; } दिया Globals.ACONSTANT बदल रहा है और केवल वैश्विक recompiling द्वि छोड़ देंगे अभी भी = 1)
अपनी खुद की सिंगलटन बिल्डिंग बगल में है। करने के लिए सबसे सरल बात, और अक्सर ठीक है (हालांकि सिंगलटन लोडिंग में अंतर्निहित समस्याओं पर विचार-विमर्श देखें, उदाहरण के लिए double-checked locking)। इस तरह के मुद्दों का एक बड़ा कारण है कि क्यों कई ऐप्स वसंत, गुइस या कुछ अन्य ढांचे का उपयोग कर बनाए जाते हैं जो संसाधन लोडिंग का प्रबंधन करते हैं।
तो मूल रूप से: स्टैटिक्स
सिंगलेट्स इनमें से कुछ को ठीक करते हैं, निर्भरता इंजेक्शन फ्रेमवर्क सिंगलटन लोडिंग में शामिल कुछ मुद्दों को ठीक और सरल बनाते हैं।
चूंकि आपकी कक्षा वैश्विक सेटिंग्स धारण कर रही है, इसलिए सिंगलटन के लिए समर्थक यह हो सकता है कि आपके पास सिंगलटन के निर्माण के बारे में अधिक नियंत्रण हो। ऑब्जेक्ट सृजन के दौरान आप कॉन्फ़िगरेशन फ़ाइल पढ़ सकते हैं।
अन्य मामलों में यदि विधियां स्थैतिक हैं तो जावा मैथ क्लास में कोई लाभ नहीं होगा, जिसमें केवल स्थिर सदस्य हैं।
सिंगलटन के लिए एक और स्पष्ट आवश्यकता तब होती है जब आप कारखानों को सिंगलेट के रूप में कार्यान्वित करते हैं, क्योंकि आप इस कारखाने के विभिन्न कार्यान्वयन का आदान-प्रदान कर सकते हैं।
सृजन पर नियंत्रण भी उस सिंगलटन पर निर्भर घटकों का परीक्षण करने में मदद करता है। –
कभी-कभी लोग सोचते हैं कि सिंगलटन ऑब्जेक्ट्स के रूप में वास्तव में एक वर्ग के निजी सदस्य हो सकते हैं। अन्य बार वे अद्वितीय वैश्विक चर होना चाहिए। इस पर निर्भर करता है कि डिजाइन को क्या होना चाहिए।
अगर वहाँ एक होना चाहिए, और बिल्कुल एक एक वस्तु का उदाहरण: एक सिंगलटन का उपयोग करें। इसके द्वारा, मेरा मतलब है कि यदि एक से अधिक ऑब्जेक्ट हैं तो प्रोग्राम को एचएएलटी होना चाहिए। एक अच्छा उदाहरण यह है कि यदि आप एक वीडियो गेम तैयार कर रहे हैं जो केवल एक आउटपुट डिवाइस को प्रतिपादन का समर्थन करता है। एक ही डिवाइस को फिर से खोलने की कोशिश कर रहा है (हार्डकोडिंग के लिए आप पर शर्म की बात है!) मना कर दिया जाएगा। आईएमएचओ इस तरह का मामला अक्सर इसका मतलब है कि आपको कक्षाओं का उपयोग पहले स्थान पर नहीं करना चाहिए। यहां तक कि सी भी आपको सिंगलटन कक्षा बनाने की जटिलता के बिना ऐसी समस्या को छोटा ढंग से encapsulating करने की अनुमति देता है, और अभी भी एक ओलटन पर लागू ओओ के तत्वों को बनाए रखने की अनुमति देता है। जब आप जावा/सी # जैसी भाषा में फंस जाते हैं, तो सिंगलटन पैटर्न वह है जो आपको काम करने के लिए मिला है, जब तक कि पूरी तरह स्थिर सदस्य स्वयं ही चाल नहीं करेंगे। आप अभी भी उन तरीकों से अनुकरण कर सकते हैं।
यदि यह केवल वस्तुओं को इंटरफेसिंग करने का मामला है, तो आपको शायद अधिक ऑब्जेक्ट उन्मुख होना चाहिए। यहां एक और उदाहरण दिया गया है: मान लीजिए कि हमारे गेम इंजन प्रतिपादन कोड को इंटरफ़ेस संसाधन और इनपुट प्रबंधक की आवश्यकता है, इसलिए यह काम कर सकता है। आप उन सिंगलेट्स को बना सकते हैं और संसाधन मैनेजर की तरह sth कर सकते हैं .getInstance()। GetResource (name)। या आप एक एप्लिकेशन क्लास (उदा। GameEngine) बना सकते हैं जिसमें संसाधन प्रबंधक और इनपुट प्रबंधक निजी सदस्य हैं। फिर गेमइंजिन को प्रतिपादन कोड के तरीकों के लिए आवश्यकतानुसार पास करें। जैसे आर। रेंडर (संसाधन प्रबंधक);
सिंगलेट्स के लिए — आसानी से कहीं से भी पहुंचा जा सकता है, यह वैश्विक चर की तरह है, लेकिन इसकी केवल एक प्रति हो सकती है।
सिंगलेट्स के खिलाफ — सिंगलेट्स के कई उपयोगों को इसे मूल ऑब्जेक्ट में encapsulating और किसी सदस्य ऑब्जेक्ट को किसी अन्य सदस्य ऑब्जेक्ट विधियों में पास करके हल किया जा सकता है।
कभी-कभी केवल एक बेवकूफ वैश्विक चर का उपयोग करना सही बात है। गोटो या एक मिश्रित (और/या) सशर्त बयान का उपयोग करने की बजाय कॉपी और पेस्ट के साथ एन बार एक ही त्रुटि हैंडलिंग कोड लिखने की बजाय।
कोड स्मार्ट, कठिन नहीं है।
मैं सिंगलटन पैटर्न को सबसे अनुचित रूप से लागू डिजाइन पैटर्न मानता हूं। ~ 12 वर्षों के सॉफ्टवेयर विकास में मैं कहूंगा कि मैंने शायद 5 उदाहरण देखे हैं जो उचित थे।
मैं एक परियोजना जहां हम एक प्रणाली की निगरानी सेवा है कि एक System वर्ग के साथ हमारी प्रणाली मॉडलिंग की थी पर काम किया (के साथ भ्रमित होने की नहीं जावा के अंतर्निहित System वर्ग) कि Component की सूची के साथ Subsystem रों प्रत्येक की एक सूची निहित एस और इतने पर। डिजाइनर ने System सिंगलटन बनाया। मैंने पूछा "यह सिंगलटन क्यों है?" उत्तर: "ठीक है, केवल एक प्रणाली है।" "मुझे पता है, लेकिन, आपने इसे सिंगलटन क्यों बनाया? क्या आप सामान्य कक्षा के एक उदाहरण को तुरंत चालू नहीं कर सकते हैं और इसे कक्षाओं में भेज सकते हैं?" "इसे पास करने के बजाय हर जगह getInstance() पर कॉल करना आसान था।" "ओह ..."
यह उदाहरण सामान्य है: तकनीकी कारणों के लिए एक अनूठा उदाहरण लागू करने के बजाए सिंगलटन अक्सर कक्षा के एक उदाहरण को एक्सेस करने के सुविधाजनक तरीके के रूप में दुरुपयोग किया जाता है। लेकिन यह एक कीमत पर आता है। जब कोई कक्षा getInstance() पर निर्भर करती है, तो यह हमेशा सिंगलटन कार्यान्वयन के लिए बाध्य होती है। यह इसे कम परीक्षण योग्य, पुन: प्रयोज्य, और विन्यास योग्य बनाता है। यह मेरे द्वारा अनुसरण किए जाने वाले मूल नियम का उल्लंघन करता है और संभवतः कुछ डिज़ाइन सिद्धांतों में निबंध का एक आम नाम है: कक्षाओं को यह नहीं पता होना चाहिए कि उनकी निर्भरताओं को कैसे तुरंत चालू किया जाए। क्यूं कर? क्योंकि यह कक्षाओं को एक साथ हार्डकोड करता है। जब एक वर्ग एक कन्स्ट्रक्टर कहता है, तो यह एक कार्यान्वयन के लिए बाध्य है। getInstance() कोई अलग नहीं है। बेहतर विकल्प क्लास में एक इंटरफ़ेस पास करना है, और कुछ और कन्स्ट्रक्टर/getInstance()/फैक्ट्री कॉल कर सकता है। यह वह जगह है जहां वसंत की तरह निर्भरता इंजेक्शन ढांचे आते हैं, हालांकि वे आवश्यक नहीं हैं (बस वास्तव में अच्छा है)।
तो सिंगलटन का उपयोग करना उचित कब है? उस दुर्लभ मामले में जहां किसी एक से अधिक को तुरंत चालू करना एप्लिकेशन को बर्बाद कर देगा। मैं सौर मंडल ऐप में दो धरती को तुरंत चालू करने के बारे में बात नहीं कर रहा हूं - यह सिर्फ एक बग है। मेरा मतलब है कि कुछ अंतर्निहित हार्डवेयर या सॉफ़्टवेयर संसाधन है जो आपके ऐप को उड़ा देगा यदि आप उसे एक से अधिक बार आवंटित/आवंटित करते हैं। यहां तक कि इस मामले में, सिंगलटन का उपयोग करने वाले वर्गों को यह नहीं पता होना चाहिए कि यह सिंगलटन है। getInstance() पर एक और केवल एक कॉल होना चाहिए जो एक इंटरफ़ेस लौटाता है जिसे उसके बाद कक्षाओं के रचनाकार/सेटर्स को पास किया जाता है। मुझे लगता है कि यह कहने का एक और तरीका यह है कि आपको सिंगलटन का "एकलता" के लिए उपयोग करना चाहिए, न कि इसकी "वैश्विक रूप से सुलभता" के लिए।
वैसे, उस परियोजना पर मैंने बताया कि System सिंगलटन था ... अच्छी तरह से System.getInstance() कई अन्य अनुचित सिंगलेट्स के साथ कोड आधार पर लगी हुई थी। एक साल बाद कुछ नई आवश्यकताएं नीचे आईं: "हम अपने सिस्टम को कई साइटों पर तैनात कर रहे हैं और सिस्टम निगरानी सेवा प्रत्येक उदाहरण की निगरानी करने में सक्षम होना चाहते हैं।" प्रत्येक उदाहरण ... हमम ...getInstance() इसे काटने वाला नहीं है :-)
तो, जहां पांच उपयुक्त स्थितियां हैं? – gustafc
ओह, कृपया इस टिप्पणी को अनदेखा करें। – DJClayworth
@gustacf: वे सभी सी ++ वर्ग थे जो कस्टम हार्डवेयर के एक टुकड़े का प्रतिनिधित्व करते थे, कड़ाई से हार्डवेयर के साथ मिलकर, जो एक बार से अधिक बार हार्डवेयर/सॉफ्टवेयर काम नहीं करेगा। पुरानी स्कूल की चीजें, और फिर भी, इसने पूरी प्रक्रिया को नीचे लाने से कई प्रक्रिया उदाहरणों को नहीं रोका। – SingleShot
आपको मॉड्यूलरेशन के लिए सिंगलेट का उपयोग करना चाहिए।
सिंगलटन में निम्नलिखित संस्थाओं की कल्पना कीजिए:
Printer prt;
HTTPInfo httpInfo;
PageConfig pgCfg;
ConnectionPool cxPool;
केस 1। कल्पना कीजिए कि आपने ऐसा नहीं किया है, लेकिन सभी स्थिर फ़ील्ड/विधियों को पकड़ने के लिए एक वर्ग। फिर आपके पास निपटने के लिए स्थिर का एक बड़ा पूल होगा।
केस 2।
आपके वर्तमान मामले में, आपने उन्हें अपने उचित वर्गों में अलग कर दिया लेकिन स्थिर संदर्भों के रूप में। फिर बहुत शोर होगा, क्योंकि हर स्थैतिक संपत्ति अब आपके लिए उपलब्ध है। यदि आपको जानकारी की आवश्यकता नहीं है, खासकर जब बहुत सारी स्थिर जानकारी है, तो आपको कोड के मौजूदा दायरे को अनियंत्रित जानकारी देखने से प्रतिबंधित करना चाहिए।
डेटा अव्यवस्था की रोकथाम रखरखाव में मदद करता है और सुनिश्चित करता है कि निर्भरता प्रतिबंधित हैं। किसी भी तरह से मुझे कोडिंग के वर्तमान दायरे में मेरे लिए क्या उपलब्ध है या उपलब्ध नहीं है, मुझे कोड को अधिक प्रभावी ढंग से मदद करता है।
केस 3 संसाधन पहचान।
सिंगलेट्स संसाधनों की आसान अप-स्केलिंग की अनुमति देते हैं। आइए हम कहें कि अब आपके पास सौदा करने के लिए एक डेटाबेस है और इसलिए, आप अपनी सभी सेटिंग्स को MyConnection क्लास में स्थिर के रूप में रखते हैं। क्या होगा यदि एक समय आया जब आपको एक से अधिक डेटाबेस से कनेक्ट करने की आवश्यकता होती है? यदि आपने सिंगलटन के रूप में कनेक्शन जानकारी को कोड किया था, तो कोड वृद्धि तुलनात्मक रूप से तुलनात्मक होगी।
केस 4 विरासत।
सिंगलटन कक्षाएं खुद को विस्तारित करने की अनुमति देती हैं। यदि आपके पास संसाधनों का एक वर्ग था, तो वे सामान्य कोड साझा कर सकते हैं। मान लीजिए कि आपके पास क्लास बेसिक प्रिंटर है जो सिंगलटन के रूप में तत्काल है। फिर आपके पास लेजर प्रिंटर है जो बेसिक प्रिंटर को बढ़ाता है।
यदि आपने स्थिर साधनों का उपयोग किया था, तो आपका कोड तोड़ देगा क्योंकि आप BasicPrinter.isAlive को LaserPrinter.isAlive के रूप में एक्सेस नहीं कर पाएंगे। फिर कोड का आपका एकल टुकड़ा विभिन्न प्रकार के प्रिंटर प्रबंधित करने में सक्षम नहीं होगा, जब तक कि आप अनावश्यक कोड न रखें।
यदि आप जावा में कोडिंग कर रहे हैं, तो आप अभी भी पूरी तरह से स्थिर सामग्री वर्ग को तुरंत चालू कर सकते हैं और इसके स्थिर गुणों तक पहुंचने के लिए इंस्टेंस संदर्भ का उपयोग कर सकते हैं। अगर किसी को ऐसा करना चाहिए, तो क्यों न सिर्फ एक सिंगलटन बनाओ?
बेशक, सिंगलटन कक्षाओं को विस्तारित करने से उनके मुद्दे इस चर्चा से परे हैं लेकिन उन मुद्दों को कम करने के सरल तरीके हैं।
केस 5 जानकारी भव्यता से बचें। जानकारी के इतने सारे टुकड़े हैं जिन्हें विश्व स्तर पर सबसे बड़े और छोटे पूर्णांक की तरह उपलब्ध कराने की आवश्यकता है। Printer.isAlive को एक दादा बनाने की अनुमति क्यों दी जानी चाहिए? एक भव्य बनाने के लिए केवल एक बहुत सीमित सेट जानकारी की अनुमति दी जानी चाहिए।
एक कहावत है: वैश्विक स्तर पर सोचें, स्थानीय रूप से कार्य करें। समान रूप से, एक प्रोग्रामर को विश्व स्तर पर सोचने के लिए सिंगलटन का उपयोग करना चाहिए लेकिन स्थानीय रूप से कार्य करना चाहिए।
प्रभावी जावा का कहना है:
Singletons आम तौर पर कुछ सिस्टम घटक आंतरिक रूप से अद्वितीय, इस तरह के एक वीडियो प्रदर्शन या फाइल सिस्टम के रूप में है कि प्रतिनिधित्व करते हैं।
तो यदि आपका घटक पूरे एप्लिकेशन में एकल उदाहरण वारंट करता है और इसमें कुछ राज्य है, तो इसे एक सिंगलटन बनाने में समझदारी होती है।
(ऊपर नंगे की तरह naikus से उधार)
कई मामलों ऊपर स्थिति एक 'उपयोगिता क्लास' है, जिसमें सभी तरीकों स्थिर हैं द्वारा नियंत्रित किया जा सकता है। लेकिन कभी-कभी सिंगलटन अभी भी पसंद किया जाता है।
एक स्टेटिक यूटिलिटी क्लास पर सिंगलटन की वकालत करने का मुख्य कारण यह है कि इसे स्थापित करने में शामिल गैर-नगण्य लागत होती है। उदाहरण के लिए यदि आपकी कक्षा फाइल सिस्टम का प्रतिनिधित्व करती है, तो इसमें कुछ प्रारंभिकता होगी, जिसे सिंगलटन के कन्स्ट्रक्टर में रखा जा सकता है लेकिन एक स्टेटिक यूटिलिटी क्लास के लिए स्टेटिक इनिशिलाइज़र में कॉल करना होगा। यदि आपके ऐप के कुछ निष्पादन फ़ाइल सिस्टम तक कभी भी एक्सेस नहीं कर सकते हैं तो एक स्टेटिक यूटिलिटी क्लास के साथ आपने अभी भी इसे शुरू करने की लागत का भुगतान किया है, भले ही आपको इसकी आवश्यकता न हो। सिंगलटन के साथ यदि आपको इसे तुरंत चालू करने की आवश्यकता नहीं है तो आप प्रारंभिक कोड को कभी भी कॉल नहीं करते हैं।
यह सब कहकर, सिंगलटन लगभग निश्चित रूप से सबसे अधिक उपयोग किए जाने वाले डिज़ाइन पैटर्न हैं।
मैं गलत हो सकता है। लेकिन मुझे लगता है कि सिंगलटन क्लास कक्षा लोडिंग समय पर एक ही उदाहरण बनाता है और स्थिर ब्लॉक वर्ग लोडिंग समय पर भी चलाया जाता है। तो दोनों मामलों में प्रारंभिक कोड केवल एक बार चलाएगा। – Vivart
ए सिंगलटन क्लास लोडिंग समय पर इसका उदाहरण नहीं बनाता है, जब यह पहला उदाहरण अनुरोध किया जाता है तो यह बनाता है। यदि कोई उदाहरण कभी अनुरोध नहीं किया जाता है तो प्रारंभिक कोड कभी नहीं चलाया जाता है। – DJClayworth
@ डीजेक्लेवर्थ: बिल्कुल। उदाहरण getInstance() के पहले अनुरोध तक या उदाहरण के लिए जो भी तरीका है, तब तक उदाहरण नहीं बनाया गया है। – Izza
नहीं, बस वैश्विक का उपयोग करें। यदि आपको एक से अधिक की आवश्यकता नहीं है, तो एक से अधिक न करें। – GManNickG