सवाल सिंगलेट्स के बारे में इतना बुरा क्या है? [बन्द है]


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

स्टैक ओवरफ़्लो विशेष रूप से लगता है कि हर कोई इस बात से सहमत है कि सिंगलेट्स बुरा हैं। क्यूं कर?

कृपया अपने उत्तरों का समर्थन करें "तथ्यों, संदर्भ, या विशिष्ट विशेषज्ञता"


1737


मूल


मुझे कहना है कि एक सिंगलटन डिजाइन का उपयोग करके मुझे हाल ही में जला दिया गया है क्योंकि मैंने कोड को अनुकूलित करने की कोशिश की है। जैसा कि मैं इसे अपने खाली समय में करता हूं, मैं इसे पुन: सक्रिय करने के लिए लगभग आलसी हूं। उत्पादकता के लिए बुरी खबर। - Marcin
उत्तरों में बहुत से 'विपक्ष' हैं, लेकिन खराब होने के विपरीत, पैटर्न के अच्छे होने के कुछ अच्छे उदाहरण भी देखना चाहेंगे ... - DGM
मैंने कुछ महीने पहले विषय पर एक ब्लॉग पोस्ट लिखा था: jalf.dk/blog/2010/03/... - और मुझे बस इसे ठीक कहने दो। मैं व्यक्तिगत रूप से एक ऐसी स्थिति के बारे में सोच नहीं सकता जहां एक सिंगलटन सही समाधान है। इसका मतलब यह नहीं है कि ऐसी स्थिति मौजूद नहीं है, लेकिन ... उन्हें दुर्लभ कहना एक अल्पमत है। - jalf
@ एडमस्मिथ इसका मतलब यह नहीं है है करने के लिए, लेकिन इसका मतलब है आप कर सकते हैं इसे इस तरह से एक्सेस करें। और यदि आप इस तरह तक पहुंचने का इरादा नहीं रखते हैं, तो इसे पहले स्थान पर सिंगलटन बनाने का कोई कारण नहीं है। तो आपका तर्क प्रभावी ढंग से है "अगर हम नहीं करते हैं तो सिंगलटन बनाने में कोई नुकसान नहीं होता है इलाज यह एक सिंगलटन के रूप में। हाँ बढ़िया। अगर मैं इसमें ड्राइव नहीं करता तो मेरी कार भी प्रदूषित नहीं होती है। लेकिन फिर पहली जगह में एक कार हासिल नहीं करना आसान है। ;) (पूर्ण प्रकटीकरण: मेरे पास वास्तव में कोई कार नहीं है) - jalf
इस पूरे विषय का सबसे बुरा हिस्सा यह है कि जो लोग सिंगलेट्स से नफरत करते हैं वे शायद ही कभी इसके लिए उपयोग करने के लिए ठोस सुझाव देते हैं। जर्नल लेखों और स्वयं प्रकाशित ब्लॉगों के लिंक इस SO लेख के माध्यम से सभी उदाहरण के लिए, क्यों और आगे चलते हैं नहीं सिंगलेट्स का उपयोग करने के लिए (और वे सभी उत्कृष्ट कारण हैं), लेकिन वे प्रतिस्थापन पर बेहद पतले हैं। हालांकि, हैंडविंग के बहुत सारे। हम में से नए प्रोग्रामर सिखाने की कोशिश क्यों कर रहे हैं क्यों सिंगलेट्स का उपयोग नहीं करना है, केवल कुछ उदाहरण के लिए इंगित करने के लिए कई अच्छे तृतीय पक्षों के काउंटररेक्समल्स नहीं हैं। यह थकाऊ है। - Ti Strga


जवाब:


ब्रायन बटन से हटाया गया:

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

  2. वे उल्लंघन करते हैं एकल जिम्मेदारी सिद्धांत: इस तथ्य के आधार पर कि वे अपनी सृजन और जीवन चक्र को नियंत्रित करते हैं।

  3. वे स्वाभाविक रूप से कोड कसकर होने का कारण बनते हैं युग्मित। यह कई मामलों में परीक्षण के तहत उन्हें बाहर खींचने में मुश्किल बनाता है।

  4. वे आवेदन के जीवनकाल के लिए चारों ओर राज्य ले जाते हैं। परीक्षण करने के लिए एक और हिट, क्योंकि आप ऐसी स्थिति के साथ समाप्त हो सकते हैं जहां परीक्षणों को आदेश दिया जाना चाहिए जो यूनिट परीक्षणों के लिए बड़ी संख्या में नहीं है। क्यूं कर? क्योंकि प्रत्येक इकाई परीक्षण दूसरे से स्वतंत्र होना चाहिए।


1148



मैं आप से असहमत हूं। चूंकि टिप्पणियों को केवल 600 वर्णों की अनुमति है, इसलिए मैंने इस पर टिप्पणी करने के लिए एक ब्लॉग पोस्ट लिखा है, कृपया नीचे दिए गए लिंक को देखें। jorudolph.wordpress.com/2009/11/22/singleton-considerations - Johannes Rudolph
बिंदु 1 और 4 पर, मुझे लगता है कि सिंगलेट्स उपयोगी हैं, और वास्तव में डेटा कैशिंग (विशेष रूप से डीबी से) के लिए लगभग सही है। मॉडलिंग यूनिट परीक्षणों में शामिल जटिलताओं को दूर तक प्रदर्शन में वृद्धि। - Dai Bok
@ दाई बोक: "कैशिंग डेटा (विशेष रूप से डीबी से)" यह करने के लिए प्रॉक्सी पैटर्न का उपयोग करें ... - paxos1977
वाह, महान प्रतिक्रियाएं। मैंने शायद यहां अत्यधिक आक्रामक शब्द का प्रयोग किया है, इसलिए कृपया ध्यान रखें कि मैं नकारात्मक रूप से तैयार प्रश्न का उत्तर दे रहा था। मेरा जवाब 'एंटी पैटर्न' की एक छोटी सूची होने के लिए था जो खराब सिंगलटन उपयोग से होता है। पूरा खुलासा; मैं भी समय-समय पर सिंगलेट का उपयोग करता हूं। एसओ पर अधिक पोषण संबंधी प्रश्न हैं जो सिंगलटन को एक अच्छा विचार माना जा सकता है जब उत्कृष्ट मंच बनाते हैं। उदाहरण के लिए, stackoverflow.com/questions/228164/... - Jim Burger
वे एक बहुप्रचारित वातावरण में कैशिंग के लिए बहुत अच्छे नहीं हैं। सीमित संसाधन पर लड़ने वाले कई धागे के साथ आप आसानी से कैश को पराजित कर सकते हैं। [एक सिंगलटन द्वारा बनाए रखा] - monksy


सिंगलेट्स एक (और केवल एक) समस्या हल करते हैं।

संसाधन अवधारणा।

यदि आपके पास कुछ संसाधन है

(1) केवल एक ही उदाहरण हो सकता है, और

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

आपको ज़रूरत है एक एकाकी वस्तु

कई उदाहरण नहीं हैं। एक लॉग फ़ाइल बड़ी है। आप सिर्फ एक लॉग फ़ाइल को छोड़ना नहीं चाहते हैं। आप इसे फ्लश करना, सिंक करना और इसे ठीक से बंद करना चाहते हैं। यह एक साझा संसाधन का एक उदाहरण है जिसे प्रबंधित किया जाना है।

यह दुर्लभ है कि आपको सिंगलटन की आवश्यकता है। वे बुरे कारण हैं कि वे एक जैसा महसूस करते हैं वैश्विक और वे गोफ के पूर्ण भुगतान वाले सदस्य हैं डिजाइन पैटर्न्स किताब।

जब आपको लगता है कि आपको वैश्विक की आवश्यकता है, तो आप शायद एक भयानक डिजाइन गलती कर रहे हैं।


399



हार्डवेयर भी एक उदाहरण सही है? एम्बेडेड सिस्टम में बहुत सारे हार्डवेयर हैं जो सिंगलेट्स का उपयोग कर सकते हैं - या शायद एक बड़ा? <मुस्कराहट> - Jeff
पूर्णतया सहमत। इस बात का कोई भी मान्यता नहीं है कि इस अभ्यास के स्थान पर हो सकता है कि इस अभ्यास के बिना चारों ओर तैरते हुए "यह अभ्यास खराब है"। अक्सर, अभ्यास केवल "बुरा" होता है क्योंकि इसका अक्सर दुरुपयोग होता है। जब तक यह उचित रूप से लागू नहीं किया जाता है तब तक सिंगलटन पैटर्न के साथ स्वाभाविक रूप से गलत कुछ भी नहीं है। - Damovisa
वास्तविक, सिद्धांत रूप से सिंगलेट बहुत दुर्लभ होते हैं (और एक प्रिंटर कतार निश्चित रूप से एक नहीं है, और न ही एक लॉग फ़ाइल है - log4j देखें)। अक्सर नहीं, हार्डवेयर सिद्धांत के बजाए संयोग से एक सिंगलटन है। पीसी से जुड़े सभी हार्डवेयर सबसे संयोग वाले सिंगलटन (एकाधिक मॉनीटर, चूहों, प्रिंटर, साउंड कार्ड्स) सोचते हैं। यहां तक ​​कि एक 500 मीओ $ कण डिटेक्टर संयोग और बजट की बाधाओं से एक सिंगलटन है - जो सॉफ़्टवेयर में लागू नहीं होता है, इस प्रकार: कोई सिंगलटन नहीं। दूरसंचार में, न तो फोन नंबर और न ही भौतिक फोन सिंगलेट हैं (आईएसडीएन, कॉल सेंटर सोचें)। - digitalarbeiter
हार्डवेयर में विभिन्न प्रकार के संसाधनों का केवल एक उदाहरण हो सकता है, लेकिन हार्डवेयर सॉफ्टवेयर नहीं है। ऐसा कोई कारण नहीं है कि विकास बोर्ड पर एक सीरियल पोर्ट को सिंगलटन के रूप में मॉडलिंग किया जाना चाहिए। दरअसल, इसे मॉडलिंग करने से केवल नए बोर्ड को बंदरगाह करना मुश्किल हो जाएगा जिसमें दो बंदरगाह हैं! - dash-tom-bang
तो आप दो समान वर्गों को लिखेंगे, बहुत सारे कोड को डुप्लिकेट करेंगे, बस आपके पास दो बंदरगाह दो बंदरगाहों का प्रतिनिधित्व कर सकते हैं? केवल दो वैश्विक सीरियलपोर्ट ऑब्जेक्ट्स का उपयोग करने के बारे में कैसे? हार्डवेयर को कक्षाओं के रूप में मॉडलिंग के बारे में कैसे नहीं? और आप सिंगलेट का उपयोग क्यों करेंगे, जो वैश्विक पहुंच का भी अर्थ है? क्या तुम चाहते हो प्रत्येक धारावाहिक बंदरगाह तक पहुंचने में सक्षम होने के लिए अपने कोड में कार्य करें? - jalf


कुछ कोडिंग स्नॉब्स उन्हें एक गौरवशाली वैश्विक के रूप में देखते हैं। इसी तरह से कई लोग नफरत करते हैं के लिए जाओ बयान में ऐसे लोग हैं जो कभी भी उपयोग करने के विचार से नफरत करते हैं वैश्विक। मैंने देखा है कि कई डेवलपर्स एक से बचने के लिए असाधारण लंबाई में जाते हैं वैश्विक क्योंकि वे विफलता के प्रवेश के रूप में एक का उपयोग करने पर विचार किया। अजीब बात है लेकिन सच है।

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


307



सिंगलटन में जो विफलता मैं देखता हूं वह यह है कि लोग ग्लोबल्स के बजाए उनका उपयोग करते हैं क्योंकि वे किसी भी तरह से "बेहतर" होते हैं। समस्या यह है (जैसा कि मैंने इसे देखा), कि चीजें जो सिंगलटन इन मामलों में तालिका में लाती हैं वे अप्रासंगिक हैं। (गैर-सिंगलटन में कार्यान्वित करने के लिए पहले-उपयोग का उपयोग करना छोटा है, उदाहरण के लिए, भले ही यह वास्तव में इसे करने के लिए कन्स्ट्रक्टर का उपयोग नहीं कर रहा हो।) - dash-tom-bang
उनके ऊपर "हम" कारण यह है कि "हम" अक्सर उन्हें गलत इस्तेमाल करते हैं, और अक्सर भी अक्सर इस्तेमाल करते हैं। "हम" जानते हैं कि उनके पास कारण है। - Bjarke Freund-Hansen
@ फिल, आपने कहा "समय-समय पर आपको लगता है कि यह आदर्श समाधान है और इसलिए इसका उपयोग करें"। ठीक है, तो बिल्कुल अंदर कौन कौन से क्या हम एक सिंगलटन उपयोगी पाएंगे? - Pacerier
@Pacerier, जब भी निम्नलिखित सभी स्थितियां होती हैं: (1) आपको केवल कुछ की आवश्यकता होती है, (2) आपको उस चीज़ को बड़ी संख्या में विधि कॉल में तर्क के रूप में पारित करने की आवश्यकता होती है, (3) आप स्वीकार करने के इच्छुक हैं हर जगह चारों ओर धुन की चीज़ों को पार न करके अपने कोड के आकार और जटिलता में तत्काल कमी के बदले में किसी दिन रिफैक्टर करने का मौका। - antinome
मुझे नहीं लगता कि यह कुछ भी जवाब देता है, यह सिर्फ इतना कहता है कि 'कभी-कभी यह फिट हो सकता है, अन्य बार यह नहीं हो सकता है'। ठीक है, लेकिन क्यों, और कब? यह उत्तर एक से अधिक क्या बनाता है संयम के लिए तर्क? - Guildenstern


Google से मिस्को हेवरी, इस विषय पर कुछ दिलचस्प लेख हैं ...

सिंगलेट्स पैथोलॉजिकल लीअर्स हैं एक यूनिट परीक्षण उदाहरण है जो दर्शाता है कि कैसे सिंगलेट्स निर्भरता श्रृंखलाओं को समझना और एप्लिकेशन को शुरू करना या परीक्षण करना मुश्किल बना सकता है। यह दुर्व्यवहार का एक काफी चरम उदाहरण है, लेकिन वह जो मुद्दा बनाता है वह अभी भी वैध है:

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

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


200



इस विषय पर मिस्को के लेख इस समय चारों ओर जाने वाली सबसे अच्छी चीज हैं। - Chris Mayer
पहला लिंक वास्तव में सिंगलेट्स के साथ किसी समस्या का समाधान नहीं करता है, बल्कि कक्षा के अंदर एक स्थिर निर्भरता मानता है। पैरामीटर में गुजरकर दिए गए उदाहरण को ठीक करना संभव है, फिर भी अभी भी सिंगलेट का उपयोग करें। - DGM
@ डीजीएम: वास्तव में - वास्तव में, लेख के 'तर्क' भाग के बीच एक विशाल तार्किक डिस्कनेक्ट है, और 'सिंगलेट्स कारण हैं' भाग। - Harper Shelby
मिस्को का क्रेडिट कार्ड लेख एक है चरम इस पैटर्न के दुरुपयोग का उदाहरण। - Alex
दूसरे लेख को पढ़ना सिंगलेट्स वास्तव में वर्णित ऑब्जेक्ट मॉडल का हिस्सा हैं। हालांकि, विश्व स्तर पर पहुंच योग्य होने के बजाय ये फैक्ट्री ऑब्जेक्ट्स के लिए निजी हैं। - FruitBreak


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

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


103



ऐप में उपलब्ध एक उदाहरण क्या है? ओह। वैश्विक। "सिंगलटन है नहीं ग्लोबल्स को लपेटने के लिए एक पैटर्न "या तो बेवकूफ या भ्रामक है, जैसा कि परिभाषा से, पैटर्न एक वैश्विक उदाहरण के आसपास एक वर्ग लपेटता है। - cHao
निस्संदेह आप अपने आवेदन शुरू होने पर कक्षा का एक उदाहरण बनाने के लिए स्वतंत्र हैं, और उस उदाहरण को इंजेक्ट करते हैं, इंटरफ़ेस के माध्यम से, इसका उपयोग करने वाले किसी भी चीज़ में। कार्यान्वयन परवाह नहीं करना चाहिए कि केवल एक ही हो सकता है। - Scott Whitlock
@ डेनियस: अंत में वास्तव में नहीं है। निश्चित रूप से, आप मनमाने ढंग से दूसरे के साथ उदाहरण को प्रतिस्थापित नहीं करते हैं। (उन चेहरे-प्रेरित क्षणों को छोड़कर जब तुम करो। मैंने वास्तव में देखा है setInstance पहले तरीकों से।) यह मुश्किल मायने रखता है, हालांकि - वेनी जिसकी "जरूरत" एक सिंगलटन को भी encapsulation या mutable वैश्विक स्थिति के साथ क्या गलत है, के बारे में एक अजीब चीज नहीं पता था, इसलिए वह मददगार (?) प्रत्येक के लिए सेटर्स प्रदान किया। एक। खेत। (और हाँ, ऐसा होता है। ए बहुत। जंगली में मैंने कभी देखा है कि लगभग हर सिंगलटन डिजाइन द्वारा उत्परिवर्तनीय था, और अक्सर शर्मनाक है।) - cHao
@ डेनियस: एक बड़ी डिग्री के लिए, हमारे पास पहले से ही है। "विरासत पर संरचना पसंद करें" काफी समय से एक बात रही है। जब विरासत है सबसे अच्छा समाधान, हालांकि, आप निश्चित रूप से इसका उपयोग करने के लिए स्वतंत्र हैं। सिंगलटन, ग्लोबल्स, थ्रेडिंग के साथ वही बात goto, आदि वे कर सकते हैं काम कई मामलों में, लेकिन स्पष्ट रूप से, "काम" पर्याप्त नहीं है - यदि आप पारंपरिक ज्ञान के खिलाफ जाना चाहते हैं, तो आप बेहतर प्रदर्शन कर सकते हैं कि आपका दृष्टिकोण कैसा है बेहतर पारंपरिक समाधान की तुलना में। और मुझे सिंगलटन पैटर्न के लिए ऐसा कोई मामला अभी तक नहीं देखना है। - cHao
अगर हम एक-दूसरे से बात करते हैं, तो मैं सिर्फ वैश्विक स्तर पर उपलब्ध उदाहरण के बारे में बात नहीं कर रहा हूं। इसके लिए बहुत सारे मामले हैं। मैं किस बारे में बात कर रहा हूं (विशेष रूप से जब मैं "पूंजी-एस सिंगलटन" कहता हूं) गोफ के सिंगलटन पैटर्न है, जो कक्षा में एक ही वैश्विक उदाहरण को एम्बेड करता है, इसे एक के माध्यम से उजागर करता है getInstanceया इसी तरह नामित विधि, और एक दूसरे उदाहरण के अस्तित्व को रोकता है। स्पष्ट रूप से, उस बिंदु पर, आप भी हो सकता है कि यह भी नहीं है एक उदाहरण। - cHao


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

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

तो मूल रूप से:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

बजाय:

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

मेरा मानना ​​है कि इस तरह के पैटर्न को बुलाया जाता है निर्भरता अन्तःक्षेपण और आमतौर पर एक अच्छी बात माना जाता है।

हालांकि किसी भी पैटर्न की तरह ... इसके बारे में सोचें और विचार करें कि दी गई स्थिति में इसका उपयोग अनुचित है या नहीं ... नियम आमतौर पर टूटा जा सकता है, और पैटर्न विचार के बिना willy nilly लागू नहीं किया जाना चाहिए।


71



हे, अगर आप इसे हर जगह करते हैं, तो आपको हर जगह सिंगलटन के संदर्भ में भी जाना होगा, और इस प्रकार आपके पास सिंगलटन नहीं होगा। :) (आमतौर पर आईएमओ की एक अच्छी बात है।) - Bjarke Freund-Hansen
@ बजेर्केफ्रुंड-हंसन - बकवास, आप किसके बारे में बात कर रहे हैं? एक सिंगलटन बस एक वर्ग का एक उदाहरण है जो एक बार instatiated है। ऐसे सिंगलटन का संदर्भ वास्तविक वस्तु की प्रतिलिपि नहीं करता है, यह सिर्फ संदर्भित करता है - आपको अभी भी वही ऑब्जेक्ट मिला है (पढ़ें: सिंगलटन)। - M. Mimpen
@ एम। मिम्पेन: नहीं, पूंजी-एस सिंगलटन (जिस पर चर्चा की जा रही है) एक वर्ग का एक उदाहरण है कि (ए) गारंटी देता है कि केवल एक उदाहरण मौजूद होगा, और (बी) कक्षा के अपने अंतर्निहित वैश्विक बिंदु के माध्यम से पहुंचा जा सकता है। अगर आपने घोषणा की है कि कुछ भी नहीं बुलाया जाना चाहिए getInstance(), तो (बी) अब और सच नहीं है। - cHao
@cHao मैं आपका अनुसरण नहीं करता या आप समझ नहीं पाते कि मैं किसके बारे में टिप्पणी करता हूं - जो बर्जके फ्रुंड-हैंनसेन के लिए है। बजेर्के का कहना है कि सिंगलटन के कई संदर्भों के परिणामस्वरूप कई सिंगलेट हैं। यह निश्चित रूप से सच नहीं है क्योंकि कोई गहरी प्रतियां नहीं हैं। - M. Mimpen
@ एम। मिम्पेन: मैं अर्थपूर्ण प्रभाव के लिए और अधिक संदर्भ देने के लिए अपनी टिप्पणी लेता हूं। एक बार जब आप कॉल को रद्द कर देते हैं getInstance(), आपने सिंगलटन पैटर्न और सामान्य संदर्भ के बीच प्रभावी रूप से एक उपयोगी अंतर को फेंक दिया है। जहां तक ​​शेष कोड का संबंध है, एकता अब संपत्ति नहीं है। केवल कॉलर getInstance() कभी भी जानना आवश्यक है कि यहां कितने उदाहरण हैं। केवल एक कॉलर के साथ, कॉलर को केवल एक संदर्भ संग्रहीत करने और इसका पुन: उपयोग करने के लिए क्लास के विश्वसनीयता को विश्वसनीय रूप से लागू करने के लिए प्रयास और लचीलापन में अधिक खर्च होता है। - cHao


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

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

में कचरा इकट्ठा मेमोरी मैनेजमेंट के संबंध में पर्यावरण सिंगलटन जल्दी ही एक मुद्दा बन सकता है।

बहु-थ्रेडेड परिदृश्य भी है जहां सिंगलेट्स एक बाधा बनने के साथ-साथ सिंक्रनाइज़ेशन समस्या भी बन सकते हैं।


65



मुझे पता है कि यह कई साल पुराना धागा है। नमस्ते @ किमोज़ ने कहा: - स्मृति प्रबंधन के संबंध में सिंगलटन जल्दी ही एक मुद्दा बन सकता है। सिंगलटन और कचरा संग्रह के संबंध में किस प्रकार की समस्या आ सकती है, इस बारे में अधिक विस्तार से समझाया जाना चाहूंगा। - Thomas
@ किमोज़, सवाल पूछ रहा है "सिंगलटन पैटर्न खुद में कोई समस्या क्यों नहीं है?" और आपने केवल बिंदु को दोहराया है लेकिन सिंगलटन पैटर्न का एक भी वैध उपयोग केस प्रदान नहीं किया है। - Pacerier
@ थॉमस, क्योंकि परिभाषा द्वारा सिंगलटन केवल एक उदाहरण में मौजूद है। तो, यह अक्सर शून्य के लिए एकमात्र संदर्भ असाइन करने के लिए जटिल है। यह किया जा सकता है, लेकिन इसका मतलब है कि आप उस बिंदु को पूरी तरह से नियंत्रित करते हैं जिसके बाद आपके ऐप में सिंगलटन का उपयोग नहीं किया जाता है। और यह दुर्लभ है, और आमतौर पर जो सिंगलटन उत्साही खोज रहे हैं उसके विपरीत काफी: एक उदाहरण बनाने का एक आसान तरीका है हमेशा सुलभ। Guice या Dagger जैसे कुछ DI framworks पर, सिंगलटन से छुटकारा पाने के लिए संभव नहीं है और यह हमेशा स्मृति में रहता है। (हालांकि कंटेनर प्रदान किया गया है सिंगलटन घर से बने लोगों की तुलना में कहीं बेहतर है)। - Snicolas


एक सिंगलटन एक स्थिर विधि का उपयोग करके लागू किया जाता है। उन लोगों द्वारा स्टेटिक विधियों से बचा जाता है जो यूनिट परीक्षण करते हैं क्योंकि उन्हें मजाक या स्टब नहीं किया जा सकता है। इस साइट पर ज्यादातर लोग यूनिट परीक्षण के बड़े समर्थक हैं। उनसे बचने के लिए आमतौर पर सबसे स्वीकार्य सम्मेलन का उपयोग कर रहा है नियंत्रण का उलटा पैटर्न।


52



यह यूनिट परीक्षण के साथ एक समस्या की तरह लगता है जो वस्तुओं (इकाइयों), कार्यों (इकाइयों), पूरे पुस्तकालयों (इकाइयों) का परीक्षण कर सकता है, लेकिन वर्ग (इकाइयों) में स्थिर कुछ भी विफल हो सकता है। - v010dya
क्या आप किसी भी तरह के सभी बाहरी संदर्भों का मकसद नहीं मानते हैं? यदि आप हैं, तो सिंगलटन के लिए क्या समस्या है, यदि नहीं, तो क्या आप वास्तव में यूनिट परीक्षण कर रहे हैं? - Dainius
@ डेनियस: मॉकिंग उदाहरणों वर्गों की नकल करने से बहुत कम परेशानी है। आप अनुमान के अनुसार कक्षा के बाकी हिस्सों से परीक्षण के तहत कक्षा को निकालने और नकली के साथ परीक्षण कर सकते हैं Singleton कक्षा। हालांकि, यह परीक्षण प्रक्रिया को अत्यधिक जटिल बनाता है। एक के लिए, अब आपको इच्छानुसार कक्षाओं को अनलोड करने में सक्षम होना चाहिए (वास्तव में अधिकांश भाषाओं में एक विकल्प नहीं), या प्रत्येक परीक्षा के लिए एक नया वीएम शुरू करें (पढ़ें: परीक्षण हजारों बार लंबे समय तक ले सकते हैं)। दो के लिए, हालांकि, पर निर्भरता Singleton एक कार्यान्वयन विस्तार है जो अब आपके सभी परीक्षणों को लीक कर रहा है। - cHao
Powermock स्थिर सामान नकली कर सकते हैं। - Snicolas


जब आता है तो सिंगलेटन भी खराब होते हैं क्लस्टरिंग। तब, आपके पास अब आपके एप्लिकेशन में "बिल्कुल एक सिंगलटन" नहीं है।

निम्न स्थितियों पर विचार करें: एक डेवलपर के रूप में, आपको एक वेब एप्लिकेशन बनाना होगा जो डेटाबेस तक पहुंचता है। यह सुनिश्चित करने के लिए कि समवर्ती डेटाबेस कॉल एक दूसरे से संघर्ष नहीं करते हैं, आप एक थ्रेड-सेव बनाते हैं SingletonDao:

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

तो आप सुनिश्चित हैं कि आपके आवेदन में केवल एक सिंगलटन मौजूद है और सभी डेटाबेस इस और केवल के माध्यम से जाते हैं SingletonDao। आपका उत्पादन वातावरण अब इस तरह दिखता है: Single Singleton

अब तक सबकुछ ठीक है।

अब, मान लें कि आप क्लस्टर में अपने वेब एप्लिकेशन के कई उदाहरण सेट अप करना चाहते हैं। अब, अचानक आप इस तरह कुछ है:

Many singletons

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

बेशक यह एक सिंगलटन के बुरे उपयोग का एक उदाहरण है। लेकिन इस उदाहरण का संदेश यह है कि आप इस बात पर भरोसा नहीं कर सकते कि आपके आवेदन में सिंगलटन का बिल्कुल एक उदाहरण है - खासकर जब क्लस्टरिंग की बात आती है।


42



यदि आप नहीं जानते कि सिंगलटन को कैसे कार्यान्वित किया जाए, तो आपको ऐसा नहीं करना चाहिए। यदि आप नहीं जानते कि आप क्या कर रहे हैं, तो आपको वह पहले मिलना चाहिए, और केवल उसके बाद आपको जो चाहिए वह करें। - Dainius
यह दिलचस्प है, मेरे पास एक सवाल है। तो सिंगललेट्स - प्रत्येक एक अलग मशीन / जेवीएम पर प्रत्येक समस्या को ठीक से क्या समस्या है? सिंगलेट्स का दायरा केवल उस विशेष JVM के लिए है, और यह अभी भी क्लस्टर में भी सत्य है। दार्शनिक रूप से यह कहने की बजाय कि यह विशेष स्थिति खराब है क्योंकि हमारा इरादा पूरे आवेदन में एक ही वस्तु थी, इसलिए मुझे इस व्यवस्था के कारण उत्पन्न होने वाली किसी भी तकनीकी समस्या को देखकर खुशी होगी। - Saurabh Patil


  1. यह आसानी से (एबी) वैश्विक चर के रूप में उपयोग किया जाता है।
  2. सिंगलेट्स पर निर्भर वर्ग जो अलगाव में इकाई परीक्षण के लिए अपेक्षाकृत कठिन हैं।

34





एकाधिकार शैतान और गैर-पठनीय / परिवर्तनीय राज्य के साथ सिंगलटन 'असली' समस्या है ...

पढ़ने के बाद सिंगलेट्स पैथोलॉजिकल लीअर्स हैं जैसा कि में सुझाव दिया गया है जेसन का जवाब मैं इस छोटी सी चीज में आया जो सबसे अच्छा प्रस्तुत उदाहरण प्रदान करता है किस तरह सिंगलेट्स का अक्सर दुरुपयोग किया जाता है।

वैश्विक खराब है क्योंकि:

  • ए। यह नामस्थान संघर्ष का कारण बनता है
  • ख। यह राज्य को एक अनचाहे फैशन में उजागर करता है

जब सिंगलेट्स की बात आती है

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

आखिरी बयान में वह 'सिंगलेट्स झूठे' के ब्लॉग की अवधारणा का जिक्र कर रहे हैं।

यह एकाधिकार पर कैसे लागू होता है?

एकाधिकार का खेल शुरू करने के लिए, पहले:

  • हम पहले नियम स्थापित करते हैं ताकि सभी एक ही पृष्ठ पर हों
  • खेल की शुरुआत में सभी को समान शुरुआत दी जाती है
  • भ्रम से बचने के लिए नियमों का केवल एक सेट प्रस्तुत किया जाता है
  • नियमों को पूरे खेल में बदलने की अनुमति नहीं है

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

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

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

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

इसलिए, यदि किसी गेम के लिए एक नियम पुस्तिका सटीक रूप से एक सिंगलटन का प्रतिनिधित्व करती है, तो एकाधिकार नियम पुस्तिका दुर्व्यवहार का एक उदाहरण होगा।

यह प्रोग्रामिंग पर कैसे लागू होता है?

सभी स्पष्ट थ्रेड-सुरक्षा और सिंक्रनाइज़ेशन मुद्दों के अलावा जो उत्परिवर्तनीय सिंगलेट्स मौजूद हैं ... यदि आपके पास डेटा का एक सेट है, जो एक साथ कई अलग-अलग स्रोतों द्वारा पढ़ने / छेड़छाड़ करने में सक्षम है और आवेदन निष्पादन के जीवनकाल के दौरान मौजूद है, शायद पीछे हटने के लिए यह एक अच्छा समय है और पूछें "क्या मैं यहां सही प्रकार की डेटा संरचना का उपयोग कर रहा हूं"।

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

एक सिंगलटन है केवल यदि आपको सिंगलटन प्रदान करता है तो एक विकल्प। एक ऑब्जेक्ट का एक लिखने वाला एकमात्र उदाहरण। वही नियम वस्तु के गुणों / सदस्यों को भी कैस्केड करना चाहिए।


30



क्या होगा अगर सिंगलटन कुछ डेटा पूछता है? - Yola
@Yola यह लिखने की संख्या पर कटौती करेगा अगर सिंगलटन को पूर्व निर्धारित और / या निश्चित शेड्यूल पर अद्यतन करने के लिए निर्धारित किया गया था, जिससे थ्रेड विवाद कम हो गया था। फिर भी, आप सिंगलटन के साथ बातचीत करने वाले किसी भी कोड का सटीक परीक्षण करने में सक्षम नहीं होंगे जबतक कि आप एक गैर-सिंगलटन उदाहरण का नकल नहीं करते जो समान उपयोग को अनुकरण करता है। टीडीडी लोगों के पास शायद फिट होगा लेकिन यह काम करेगा। - Evan Plaice
@EvanPlaice: यहां तक ​​कि एक नकली के साथ, आपको कोड के साथ कुछ समस्याएं होंगी जो कहती हैं Singleton.getInstance()। प्रतिबिंब का समर्थन करने वाली एक भाषा उस क्षेत्र को सेट करके उस पर काम करने में सक्षम हो सकती है जहां एक ट्रू इंस्टेंस संग्रहीत किया जाता है। आईएमओ, हालांकि, एक बार जब आप किसी अन्य वर्ग के निजी राज्य के साथ बंदरगाह करने के लिए ले जाते हैं तो परीक्षण थोड़ा कम भरोसेमंद हो जाते हैं। - cHao