एक उद्देश्य-सी सिंगलटन

Question

पूरी तरह से हटा रहा है मैं सिंगलेट लिखने के लिए नया हूं और मुझे वर्तमान आईओएस प्रोजेक्ट के लिए एक का उपयोग करना है। आवश्यकताओं में से एक यह है कि इसे मारा जा सकता है। मुझे पता है कि यह एक सिंगलटन के डिजाइन के खिलाफ चला जाता है, लेकिन क्या ऐसा कुछ है जो किया जाना चाहिए/किया जा सकता है?

Answer 1

बेशक यह किया जा सकता है, लेकिन यदि आप किसी ऑब्जेक्ट की तलाश कर रहे हैं जिसे बनाया जा सकता है, और तब आवश्यक होने पर रिलीज़ किया जाता है ... जो नियमित ऑब्जेक्ट की तरह लगता है। :)

---

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

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

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

अनिवार्य रूप से, मुझे एक ऐसे मामले का निर्माण करने के लिए कड़ी मेहनत की जाएगी जहां इसे वास्तव में सिंगलटन ऑब्जेक्ट जारी करने के लिए वास्तव में समझ में आया। एक मूलभूत वस्तु स्मृति में केवल कुछ मुट्ठी बाइट लेती है, और किसी को भी लटककर दर्द नहीं होता है।

Answer 2

निश्चित रूप से कोई समस्या नहीं है। आप एक नई कक्षा विधि प्रदान करते हैं: [MyClass killSingleton]; वह विधि सिंगलटन को रिलीज़ करती है और शून्य के आंतरिक संदर्भ को सेट करती है। अगली बार जब कोई [MyClass SharedSingleton] पूछता है, तो आप इसे बनाने के लिए पहले किए गए चरणों के माध्यम से जाते हैं।

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

Answer 3

मैं इस एक सिंगलटन

यह भी ऑब्जेक्टिव-सी में सामान्य स्मृति प्रबंधन पैटन के खिलाफ जाता है के डिजाइन के खिलाफ जाता है पता है। आम तौर पर, किसी वस्तु को नष्ट होने से रोकने के लिए एक और वस्तु को बनाए रखने के लिए, और ऑब्जेक्ट को नष्ट करने की अनुमति देने के लिए इसे रिलीज़ करने के लिए मिलता है। स्पष्ट रूप से किसी वस्तु को नष्ट करना, ऐसा कुछ नहीं है जो अन्य वस्तुओं को करने के लिए मिलता है।

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

आप -retain ओवरराइड करके इस समस्या को हल करने में सक्षम हो सकते हैं और शायद -release को तेज कर सकते हैं, लेकिन यह ऐसी समस्या को हल करने के लिए बहुत जटिलता की तरह लगता है जो पहले स्थान पर मौजूद नहीं होना चाहिए।

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

Answer 4

बस मैंने जो भी सिंगलटन लिखा है (पूरी तरह से यूआई केंद्रित नियंत्रकों के लिए सहेजें) अंततः एकल होने के रूप में पुन: सक्रिय नहीं किया जा रहा है। प्रत्येक। एक। एक।

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

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

कहा कक्षा में आंसू कोड शामिल है जो आम तौर पर दो टुकड़ों में विभाजित होता है; बाद में बहाली के लिए वर्तमान स्थिति को जारी रखने के लिए कोड और कोड जो उदाहरण संबंधित संसाधनों को जारी करता है।

एक सिंगलटन की तरह सुविधाजनक। आवश्यकता होने पर तत्काल गुणा करने के लिए तैयार।

Answer 5

यह सिंगलटन की अवधारणा के खिलाफ है, लेकिन यह एक एआरसी आधारित परियोजना

//ARC 
@interface Singleton : NSObject 

+ (Singleton *)sharedInstance; 
+ (void)selfDestruct; 

@end 

@implementation Singleton 

static Singleton *sharedInstance = nil; 

+ (Singleton *)sharedInstance { 
    if (sharedInstance == nil) { 
     sharedInstance = [[Singleton alloc] init]; 
    } 
    return sharedInstance; 
} 

+ (void) selfDestruct { 
    sharedInstance = nil; 
} 

@end 

Answer 6

//This can be implemented using bool variable. If bool no create new instance. 

@interface Singleton : NSObject 

+ (Singleton *)sharedInstance; 

@end 

@implementation Singleton 

static Singleton *sharedInstance = nil; 

+ (Singleton *)sharedInstance { 

     if (!keepInstance) { 
       sharedInstance = [[Singleton alloc] init]; 
       keepInstance = YES; 
     } 
     return sharedInstance; 
} 

@end 

Answer 7

मैं सिंगलटन को साफ करने की जरूरत के लिए नीचे दिए तरीक़े लागू किया जा सकता तो मैं निम्न कार्य समाप्त हो गया:

- (void)deleteSingleton{ 
@synchronized(self) { 
    if (sharedConfigSingletone != nil) { 
     sharedConfigSingletone = nil; 
    } 
} 
} 

उम्मीद है कि यह मदद करता है।