मैंने एसओ में कुछ लोगों को टिप्पणी की है कि सिंगलटन पैटर्न एक विरोधी पैटर्न है। मैं जानना चाहता हूं क्यो ?जावा कोड में सिंगलटन पैटर्न को कार्यान्वित क्यों करना है (कभी-कभी) जावा दुनिया में एंटी-पैटर्न माना जाता है?
परीक्षण
एक कारण यह है कि एकमात्र इकाई परीक्षण के साथ संभाल करने के लिए आसान नहीं हैं। आप तत्काल नियंत्रण को नियंत्रित नहीं कर सकते हैं और उनकी प्रकृति द्वारा राज्यों को इनवोकेशन में बरकरार रखा जा सकता है।
इसी कारण से dependency injection का सिद्धांत लोकप्रिय है। प्रत्येक वर्ग को उन वर्गों के साथ इंजेक्शन (कॉन्फ़िगर किया जाता है) जिन्हें वे काम करने की आवश्यकता होती है (सिंगलटन एक्सेसर्स के माध्यम से प्राप्त करने के बजाए) और इसलिए परीक्षण नियंत्रित कर सकते हैं कि कौन से निर्भर वर्ग उदाहरणों का उपयोग करना है (और यदि आवश्यक हो तो मैक्स प्रदान करें)।
वसंत जैसे ढांचे उनकी वस्तुओं के जीवन चक्र को नियंत्रित करेंगे और अक्सर सिंगलेट बनाते हैं, लेकिन इन वस्तुओं को ढांचे द्वारा उनकी आश्रित वस्तुओं में इंजेक्शन दिया जाता है। इस प्रकार कोडबेस स्वयं वस्तुओं को सिंगलेट के रूप में नहीं मानता है।
उदा बजाय इस (उदाहरण के लिए)
public class Portfolio {
private Calculator calc = Calculator.getCalculator();
}
आप कैलकुलेटर डालेगी:
public class Portfolio {
public Portfolio(Calculator c) {
this.calc = c;
}
}
इस प्रकार Portfolio वस्तु के बारे में कैसे Calculator के कई उदाहरणों मौजूद/देखभाल नहीं जानता है। टेस्ट एक डमी Calculator इंजेक्ट कर सकते हैं जो परीक्षण को आसान बनाता है।
कन्करेंसी
एक वस्तु का एक उदाहरण के लिए अपने आप को सीमित करके, सूत्रण के लिए विकल्प सीमित हैं। सिंगलटन ऑब्जेक्ट तक पहुंच को संरक्षित किया जाना चाहिए (उदा। सिंक्रनाइज़ेशन के माध्यम से)। यदि आप उन वस्तुओं के कई उदाहरणों को बनाए रख सकते हैं, तो आप अपने द्वारा चलाए गए धागे के उदाहरणों की संख्या बना सकते हैं, और अपने कोडबेस की समवर्ती क्षमताओं को बढ़ा सकते हैं।
तो लोग यह कैसे है कि एकमात्र का उपयोग "परीक्षण" और "के साथ सौदा करते हैं Concurrency "मुद्दों? कुछ कठिनाई के साथ – Pacerier
। पावरमैक जैसे टूल्स सिंगलटन विधियों को ओवरराइड करने के साधन प्रदान कर सकते हैं, लेकिन वे बाइटकोड मैनिपुलेशन –
मेरी व्यक्तिगत राय यह है कि यह एक जिम्मेदारी सिद्धांत का उल्लंघन करता है। सिंगलटन ऑब्जेक्ट्स उनके उद्देश्य और उनके द्वारा उत्पन्न किए जाने वाले उदाहरणों की संख्या को नियंत्रित करने के लिए ज़िम्मेदार हैं जो मुझे लगता है कि गलत है।
यही कारण है कि बहुत से लोग फैक्ट्री ऑब्जेक्ट पर नियंत्रण का प्रतिनिधित्व करते हैं।
का उपयोग करने वाले जटिल उपकरण हैं, मुझे लगता है कि बस [एसआरपी संदिग्ध] की व्याख्या करता है। –
किस तरह से संदिग्ध? – MikePatel
इसमें संदिग्ध यह स्पष्ट रूप से ऐसी चीज नहीं है जो सिंगलेट्स के साथ गलत है, लेकिन एसआरपी की व्याख्या से संकेत मिलता है कि यह है। एसआरपी (या इसकी व्याख्या) दोषी पार्टी के रूप में दिखाई देगी। –
आप सिंगलटन पर हो सकता है कि कई आवश्यकताएँ हैं:
आमतौर पर, भी, आप एकमात्र की एक पूरी बहुत कुछ अपने अनुप्रयोग में होगा, और सिंगलटन पैटर्न पुन: प्रयोज्य कोड की अनुमति नहीं है। इसलिए, यदि आप अपने सभी सिंगलेट्स के लिए इन सभी चिंताओं को लागू करना चाहते हैं, तो आप तुरंत एंटी-पैटर्न गुणवत्ता देखेंगे।
सिंगलेट्स आवश्यक रूप से एक विरोधी पैटर्न नहीं हैं, लेकिन उनके पास केवल कुछ फायदे हैं और जब वे गलत उपयोग होते हैं (जो अक्सर होता है) तो एंटीपाटर बन जाते हैं।
अक्सर, सिंगलेट अकेले सिंगलटन नहीं होते हैं, लेकिन "छिपाने में वैश्विक चर"। साथ ही, अक्सर उनका उपयोग तब किया जाता है जब "केवल एक उदाहरण" संपत्ति वास्तव में एक लाभ नहीं है। (जो इस तथ्य से संतुलित है कि कई बार कार्यान्वयन एक ही समय में गलत है)।
इसके अलावा, वे मल्टीथ्रेडिंग के साथ दिमाग में अक्सर काम करने के लिए मुश्किल हो सकते हैं (अक्सर गलत या अक्षमता से किया जाता है), और यदि आप अपने तत्काल नियंत्रण को नियंत्रित करना चाहते हैं तो वे अपने अधिकांश लाभ खो देते हैं।
यदि आप तत्कालता पर नियंत्रण रखना चाहते हैं, तो आपको कार्यक्रम के शुरुआती बिंदु पर हाथ से इसे करने की ज़रूरत है, लेकिन फिर आप बस एक सामान्य वस्तु का एक उदाहरण बना सकते हैं और आगे बढ़ सकते हैं।
यदि विनाश का आदेश किसी भी चिंता का है, तो आपको इसे मैन्युअल रूप से कार्यान्वित करने की आवश्यकता है। मुख्य समारोह में एक एकल स्वचालित वस्तु बस इतना साफ और आसान है।
[उत्परिवर्ती] सिंगलटन एक विरोधी पैटर्न का एक विरोधी पैटर्न है।
महत्वपूर्ण अंतर्निहित विरोधी पैटर्न वैश्विक स्थिति (या परिवेश राज्य) है। वैश्विक स्थिति के साथ आपके पास अपने कार्यक्रम में निर्भरता का एक बड़ा ब्लॉग है। यह परीक्षण को प्रभावित करता है, लेकिन यह खराब प्रोग्रामिंग से गिरावट का सिर्फ एक हिस्सा है।
उस पर स्तरित, सिंगलटन आसानी से परिवर्तनीय static फ़ील्ड घोषित करने पर जटिलता के अनावश्यक स्तर को जोड़ता है।
म्यूटेबल स्थिर खेतों में एक ही सटीक समस्या से पीड़ित है, यह वैश्विक स्थिति है। मैं यह देखने में असफल रहा कि स्थिर फ़ील्ड का उपयोग सिंगलटन से बेहतर कैसे है। इसके बारे में कोई जानकारी? –
@ जुआनमेन्डेस जैसा कि मैंने कहा है, सीधा म्यूटेबल स्टेटिक्स सिंगलटन म्यूटेबल स्टेटिक्स से बेहतर है क्योंकि उनके पास व्यर्थ जटिलता नहीं है। –
मुझे टिप्पणी छोड़ने से पहले बेहतर उत्तरों की समीक्षा करनी चाहिए। 100% आपसे सहमत हैं। यह मूल रूप से वैश्विक राज्य के लिए एक उदारता है, इसलिए इसे कम से कम स्थिर क्षेत्रों को बुलाकर इसे सजाए जाने की कोशिश नहीं की जाती है। –
अजीब। ऐसा लगता है कि सिंगलटन का गलत कार्यान्वयन एक "एंटी-पैटर्न" है, न कि सिंगलटन स्वयं।
मुझे लगता है कि हम भूल गए हैं कि हर कार्यक्रम को कहीं से शुरू करना है। प्रत्येक अमूर्तता का एक ठोस कार्यान्वयन होना आवश्यक है, और अंत में प्रत्येक निर्भरता को अंततः हल किया जाएगा, या आपका ऐप अधिक उपयोग नहीं करेगा।
अधिकांश डी ढांचे एक वर्ग को सिंगलटन के रूप में तुरंत चालू करने की अनुमति देते हैं, यह सिर्फ आपके लिए इसे संभालता है। यदि आप स्वयं डीआई करना चुनते हैं, तो सिंगलटन इंजेक्शन करना कोई समस्या नहीं है। एक सिंगलटन भी टेस्टेबल है, और यदि आप इसे इंजेक्ट करने के लिए DI का उपयोग कर रहे हैं, तो कक्षा को अस्थिर नहीं बनाता है।
आईएमओ, वहां हर दूसरे पैटर्न (डीआई और आईओसी सहित) की तरह यह एक उपकरण है। कभी-कभी यह फिट बैठता है, कभी-कभी ऐसा नहीं होता है।
[सिंगलटन डिजाइन पैटर्न: नुकसान] के संभावित डुप्लिकेट (http://stackoverflow.com/questions/1448393/singleton-design-pattern-pitfalls) – msw