सिंगलटन पैटर्न के तीन युग

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

1994 में, प्रसिद्ध पुस्तक डिज़ाइन पैटर्न प्रकाशित किया गया था, जिसमें 22 अन्य लोगों के बीच जनता को पेश किया गया था, और हमारे नायक, जिन्हें अब सिंगलटन कहा जाता है। उनका C ++ कार्यान्वयन इस प्रकार था:

//.h class Singleton { public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; } //.cpp Singleton* Singleton::_instance = 0; Singleton* Singleton::Instance() { if(_instance == 0){ _instance = new Singleton; } return _instance; } 

जैसा कि प्रवाह के लिए, लेखक थोड़ा प्रासंगिकता की इस समस्या को देखते हुए, उनके बारे में भी नहीं लिखते हैं। लेकिन एक दूसरे से ऐसी कक्षाओं की विरासत की सभी सूक्ष्मताओं पर बहुत ध्यान दिया गया था।

कोई आश्चर्य नहीं - यह 1995 था, और मल्टीटास्किंग ऑपरेटिंग सिस्टम किसी को भी शर्मिंदा करने के लिए बहुत धीमा था।

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

1995 में, स्कॉट मायर्स ने C ++ ट्रिक्स पर अपनी दूसरी पुस्तक जारी की। अन्य बातों के अलावा, वह उसे स्थिर कक्षाओं के बजाय सिंग्लटन का उपयोग करने के लिए प्रोत्साहित करता है - ताकि स्मृति को बचाया जा सके और यह जान सके कि इसके निर्माता को कब निष्पादित किया जाएगा।

यह इस पुस्तक में था कि विहित सिंगलटन मायर्स दिखाई दिया और मुझे इसे यहां नहीं लाने का कोई कारण नहीं दिखता है:

 class singleton { public: static singleton* instance() { static singleton inst; return &inst; } private: singleton() {} }; 

नीच, संक्षिप्त और कुशलता से भाषा के मानक को हराया। किसी फ़ंक्शन में एक स्थानीय स्थिर वैरिएबल कहा जाएगा यदि और केवल यदि फ़ंक्शन स्वयं कहा जाता है।

फिर इसका विस्तार किया गया, थोड़ा और संचालन पर प्रतिबंध लगाते हुए:

 class CMySingleton { public: static CMySingleton& Instance() { static CMySingleton singleton; return singleton; } // Other non-static member functions private: CMySingleton() {} // Private constructor ~CMySingleton() {} CMySingleton(const CMySingleton&); // Prevent copy-construction CMySingleton& operator=(const CMySingleton&); // Prevent assignment }; 

नए C ++ 11 मानक के अनुसार, थ्रेड्स का समर्थन करने के लिए अधिक कुछ नहीं चाहिए। लेकिन सभी कंपाइलरों को अभी भी इसके पूर्ण समर्थन के लिए रहने की जरूरत है।

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

2004 में, मेयर्स और एलेक्जेंड्रेस्कु ने डबल-चेक लॉकिंग के साथ सिंग्लटन का वर्णन करने के लिए बलों में शामिल हो गए। विचार सरल है - अगर पहले में एक सिंगलटन नहीं मिला है, तो हम एक लॉक बनाते हैं और इसे फिर से अंदर जांचते हैं।

इस बीच, ट्रायल और केस, थ्रेड-सेफ सिंगलटन की समस्या अन्य सी-लाइक भाषाओं में क्रॉल हो गई। पहले जावा में, और फिर C # में। और अब जॉन स्कीट समाधानों की एक पूरी श्रृंखला प्रदान करता है, जिनमें से प्रत्येक में इसके पेशेवरों और विपक्ष हैं। और वे माइक्रोसॉफ्ट द्वारा भी पेश किए जाते हैं।

शुरुआत के लिए - डबल-चेक लॉकिंग के साथ एक ही विकल्प। Microsoft इसे इस तरह लिखने की सलाह देता है:

 using System; public sealed class Singleton { private static volatile Singleton instance; private static object syncRoot = new Object(); private Singleton() {} public static Singleton Instance { get { if (instance == null) { lock (syncRoot) { if (instance == null) instance = new Singleton(); } } return instance; } } } 

हालांकि, स्कीट का मानना ​​है कि यह कोड खराब है। क्यों?

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

स्ट्रीमिंग इंटरफेस का उपयोग किए बिना भी विकल्प थे।

विशेष रूप से, पठनीय क्षेत्र के माध्यम से प्रसिद्ध कार्यान्वयन। स्कीट (और Microsoft) के अनुसार, यह पहला उल्लेखनीय विकल्प है: यहाँ ऐसा दिखता है:

 public sealed class Singleton { private static readonly Singleton instance = new Singleton(); // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Singleton() { } private Singleton() { } public static Singleton Instance { get { return instance; } } } 

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

क्या इस कार्यान्वयन से कोई नुकसान है? बेशक, हाँ:

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

अंत में, एक नेस्टेड वर्ग के साथ प्रसिद्ध आलसी कार्यान्वयन।

 public sealed class Singleton { private Singleton() { } public static Singleton Instance { get { return Nested.instance; } } private class Nested { // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Nested() { } internal static readonly Singleton instance = new Singleton(); } } 

इसका दोष किसी भी अन्य कोड के समान है जो नेस्टेड कक्षाओं का उपयोग करता है।

C # के हाल के संस्करणों में, System.Lazy वर्ग सामने आया है, जो इन सभी का संक्षिप्त रूप है। इसलिए, कार्यान्वयन और भी छोटा हो गया है:

 public sealed class Singleton { private static readonly Lazy<Singleton> lazy = new Lazy<Singleton>(() => new Singleton()); public static Singleton Instance { get { return lazy.Value; } } private Singleton() { } } 

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

यह "धोखा" भाषा के लिए अच्छा क्यों नहीं है? क्योंकि प्रत्येक ऐसे "हैक" गलती से टूटने के लिए बहुत आसान है। और क्योंकि अन्य भाषाओं में लिखने वाले लोगों से उन्हें कोई लाभ नहीं है - और फिर भी यह पैटर्न सार्वभौमिकता को दर्शाता है।

व्यक्तिगत रूप से, मुझे लगता है कि प्रवाह की समस्या को मानक तरीकों से हल किया जाना चाहिए। मल्टीथ्रेडिंग के साथ काम करने के लिए C # में कई अंतर्निहित कक्षाएं और पूरे कीवर्ड हैं। संकलक को "ट्रिक" करने के बजाय मानक टूल का उपयोग क्यों न करें।

जैसा कि मैंने कहा, ताला सबसे अच्छा समाधान नहीं है। तथ्य यह है कि संकलक इस तरह के एक लॉक (obj) को चित्रित करता है:

 lock(this) { // other code } 

इस कोड की तरह कुछ:

 Boolean lockTaken = false; try { Monitor.Enter(this, ref lockTaken); // other code } finally { if(lockTaken) Monitor.Exit(this); } 

जेफरी रिक्टर इस कोड को बहुत असफल मानते हैं। पहला, कोशिश बहुत धीमी है। दूसरी बात, अगर दुर्घटना की कोशिश की जाती है, तो कोड में कुछ गलत है। और जब दूसरा धागा इसे निष्पादित करना शुरू करता है, तो त्रुटि फिर से होने की संभावना होगी। इसलिए, वह नियमित प्रवाह के लिए Monitor.Enter / Monitor.Exit का उपयोग करने के लिए कहता है, और परमाणु संचालन के लिए सिंगलटन को फिर से लिखता है। इस तरह:

 public sealed class Singleton { private static readonly Object s_lock = new Object(); private static Singleton instance = null; private Singleton() { } public static Singleton Instance { get { if(instance != null) return instance; Monitor.Enter(s_lock); Singleton temp = new Singleton(); Interlocked.Exchange(ref instance, temp); Monitor.Exit(s_lock); return instance; } } } 

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

इस प्रकार, एक जगह और डबल-लॉक था

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