रेक 1: लोनली फीनिक्स का उदय

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

जेली

तो, एक शुरुआत के लिए, रेक ही। विरासत में मिली परियोजना में, अकेला वर्ग सक्रिय रूप से उपयोग किया गया था। दस से अधिक थे। पहली कॉल पर डायनेमिक इंस्टेंटेशन का उपयोग किया गया था, अर्थात्। getInstance मेथड इस प्रकार था

Singleton* Singleton::getInstance() { if (sInstance == NULL) { sInstance = new Singleton; } return sInstance; } 

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

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

1. कुंवारे वर्गों के आधार पर, कक्षाओं और मॉड्यूल के इंटरफेस से यह स्पष्ट नहीं है, यह पता लगाने के लिए कि प्रत्यक्ष कार्यान्वयन की जांच करना आवश्यक है, जो हमेशा आसान और संभव नहीं होता है
2. एक एकल वर्ग में एक स्पष्ट स्वामी नहीं होता है। इसलिए वह कुंवारा है। उससे और पीड़ित।

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

सब कुछ सही ढंग से नष्ट हो गया था। लेकिन अनियंत्रित निर्भरता कुंवारे लोगों के बीच मौजूद थी। अक्सर विध्वंसक में एक का उपयोग दूसरे द्वारा किया जाता था। और जब से getInstance ने न केवल कक्षा का एक मौजूदा उदाहरण लौटाया, बल्कि नए को भी बनाया, यदि आवश्यक हो, तो राख से बड़े पैमाने पर अनियंत्रित विद्रोह होने लगे। मुझे तुरंत अलेक्जेंड्रेस्कु [1] की किताब याद आ गई। केवल, मेरे विपरीत, वह नेक्रोमेंसी (खंड 6.6 में, जो लगभग प्रतीकात्मक है) जानबूझकर किया गया था।

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

निष्कर्ष

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

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

उदाहरण के लिए, कीबोर्ड, प्रदर्शन और लॉग के साथ एक उत्कृष्ट उदाहरण [1]। ये वर्ग वैश्विक अनुप्रयोग के स्वामित्व में हो सकते हैं। नाम पस्त है, लेकिन यहां इसके फायदे हैं

• निश्चितता । आवेदन :: नि: शुल्क कॉल करने के बाद, आप ज़ोंबी फीनिक्स से डर नहीं सकते - सब कुछ ठीक उसी क्रम में नष्ट हो जाएगा जिसमें डेवलपर ने इरादा किया था। अन्य साधारण वस्तुओं को हटाने के बाद हटाए गए mLog ऑपरेटर को अंतिम सरल कॉल द्वारा लॉग को हटा दिया जाता है।
• सादगी और पोर्टेबिलिटी । भाषा की सूक्ष्मताओं का उपयोग (और यहां तक ​​कि ज्ञान) की आवश्यकता नहीं है। वास्तुकला स्वतंत्र रूप से मुख्य वस्तु-उन्मुख भाषाओं के लिए अनुकूल है। इसके अलावा, सरल समाधान बहुत कम त्रुटि वाले होते हैं और कर्मचारियों की योग्यता के लिए कम आवश्यकताएं होती हैं। दूसरे शब्दों में, वे जटिल से सस्ते और बेहतर हैं [3]
• परीक्षण करने की क्षमता । एकल वर्गों के विनाश की योजना बनाने के लिए एटैक्सिट [1,2] जैसी चाल का उपयोग करना पूरी तरह से इसे बंद किए बिना आवेदन की वैश्विक स्थिति को रीसेट करना असंभव बनाता है। नतीजतन, उदाहरण के लिए, दो स्वतंत्र परीक्षणों को चलाने के लिए, आपको प्रत्येक बार कार्यक्रम को पुनरारंभ करना होगा।

एकमात्र समस्या इन वर्गों के अनियंत्रित निर्माण / नकल हो सकती है। इसलिए, सैद्धांतिक रूप से, प्रोग्रामर को यह नहीं लग सकता है कि कीबोर्ड नियंत्रण ऑब्जेक्ट को एप्लिकेशन से प्राप्त करने की आवश्यकता है, और अपना स्वयं का उदाहरण बनाएं। घटनाओं के इस तरह के विकास को सभी अवांछित निर्माणकर्ताओं को बंद घोषित करके आसानी से दबाया जा सकता है। यह "मैनुअल" निर्माण को असंभव बना देगा। ताकि स्वामी वर्ग अभी भी कीबोर्ड ऑब्जेक्ट को तुरंत हटा सके, बस इसे एक मित्र घोषित करें।

 class Keyboard { private: Keyboard(); friend class Application; }; 

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

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

[१] अलेक्जेंड्रेस्क्यू ए। सी। में आधुनिक डिज़ाइन: सामान्यीकृत प्रोग्रामिंग और अनुप्रयुक्त डिज़ाइन पैटर्न।
[२] अलौकिक
[3] KISS