🍸 🤱🏾 🏝️ सिंगलटन और ऑब्जेक्ट लाइफटाइम 👃 ⛹🏾 🥄

यह लेख मेरे पहले लेख, "सिंगलटन पैटर्न का उपयोग" [0] का एक निरंतरता है। सबसे पहले मैं इस लेख में जीवनकाल से जुड़ी हर चीज को सेट करना चाहता था, लेकिन सामग्री की मात्रा बड़ी हो गई थी, इसलिए मैंने इसे कई हिस्सों में तोड़ने का फैसला किया। यह विभिन्न टेम्पलेट्स और तकनीकों के उपयोग के बारे में लेखों की एक श्रृंखला की निरंतरता है। यह लेख सिंगलटन के उपयोग के जीवनकाल और विकास पर केंद्रित है। दूसरे लेख को पढ़ने से पहले, यह दृढ़ता से अनुशंसा की जाती है कि आप मेरा पहला लेख पढ़ें [को ०] ।

पिछले लेख में, सिंगलटन के लिए निम्नलिखित कार्यान्वयन का उपयोग किया गया था:

template<typename T> T& single() { static T t; return t; }

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

यह सिर्फ इतना हुआ कि C ++ में कोई कचरा कलेक्टर नहीं है, इसलिए आपको ऑब्जेक्ट के निर्माण और विनाश की निगरानी करने की आवश्यकता है। और यद्यपि यह समस्या लंबे समय से ज्ञात है और इसे हल करने के तरीके भी स्पष्ट हैं, इस तरह की त्रुटि हमारे कार्यक्रमों में एक दुर्लभ अतिथि नहीं है। सामान्य तौर पर, हम निम्नलिखित प्रकार की त्रुटियों को अलग कर सकते हैं जो प्रोग्रामर बनाते हैं:

जब कोई ऑब्जेक्ट नहीं बनाया जाता है तो मेमोरी का उपयोग।
पहले से हटाई गई ऑब्जेक्ट का मेमोरी उपयोग।
ऑब्जेक्ट द्वारा कब्जा की गई गैर-मुक्त मेमोरी।

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

एक सिंगलटन के उदाहरण का उपयोग करके, आप आसानी से दिखा सकते हैं कि इस तरह की त्रुटियां कैसे होती हैं। हम विकिपीडिया लेख [1] खोलते हैं और C ++ के लिए कार्यान्वयन पाते हैं:

 class OnlyOne { public: static OnlyOne* Instance() { if(theSingleInstance==0) theSingleInstance=new OnlyOne; return theSingleInstance; } private: static OnlyOne* theSingleInstance; OnlyOne(){}; }; OnlyOne* OnlyOne::theSingleInstance=0;

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

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

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

अपने लिए विभिन्न सॉफ्टवेयर उत्पादों के स्रोत कोड का विश्लेषण करते हुए, मैंने 2 और महत्वपूर्ण नियमों की पहचान की:

नया प्रयोग न करें।
डिलीट का इस्तेमाल न करें।

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

स्मार्ट पॉइंटर्स

सौभाग्य से, C ++ में एक शानदार टूल है जिसे स्मार्ट पॉइंटर कहा जाता है। उनकी चतुराई यह है कि, हालांकि वे सामान्य बिंदुओं की तरह व्यवहार करते हैं, वे वस्तुओं के जीवनकाल को भी नियंत्रित करते हैं। ऐसा करने के लिए, वे एक काउंटर का उपयोग करते हैं जो स्वतंत्र रूप से ऑब्जेक्ट के लिंक की संख्या को गिनता है। जब काउंटर शून्य तक पहुंच जाता है, तो ऑब्जेक्ट स्वचालित रूप से नष्ट हो जाता है। हम स्मार्ट हेडर का उपयोग मेमोरी हेडर फ़ाइल के मानक std :: shared_ptr लाइब्रेरी से करेंगे। यह ध्यान देने योग्य है कि इस तरह के एक वर्ग आधुनिक संकलक के लिए उपलब्ध है जो C ++ 0x मानक का समर्थन करते हैं। पुराने संकलक का उपयोग करने वालों के लिए, बढ़ावा :: साझा_प्ट्र का उपयोग किया जा सकता है। उनके इंटरफेस बिल्कुल समान हैं।

हम अपने वर्ग को निम्नलिखित कर्तव्य सौंपते हैं:

स्मार्ट पॉइंटर्स का उपयोग करके वस्तुओं के जीवनकाल को नियंत्रित करें।
कॉलिंग कोड में नए ऑपरेटरों का उपयोग किए बिना, व्युत्पन्न वर्गों सहित उदाहरण बनाना।

निम्नलिखित कार्यान्वयन इन स्थितियों को संतुष्ट करता है:

 template<typename T> struct An { template<typename U> friend struct An; An() {} template<typename U> An(const An<U>& a) : data(a.data) {} template<typename U> An(An<U>&& a) : data(std::move(a.data)) {} T* operator->() { return get0(); } const T* operator->() const { return get0(); } bool isEmpty() const { return !data; } void clear() { data.reset(); } void init() { if (!data) reinit(); } void reinit() { anFill(*this); } T& create() { return create<T>(); } template<typename U> U& create() { U* u = new U; data.reset(u); return *u; } template<typename U> void produce(U&& u) { anProduce(*this, u); } template<typename U> void copy(const An<U>& a) { data.reset(new U(*a.data)); } private: T* get0() const { const_cast<An*>(this)->init(); return data.get(); } std::shared_ptr<T> data; };

प्रस्तावित कार्यान्वयन पर अधिक विस्तार से ध्यान देना आवश्यक है:

निर्माणकर्ता प्रतिलिपि प्रदर्शन को बढ़ाने के लिए C ++ 0x मानक से चाल शब्दार्थ [6] का उपयोग करता है।
बनाने की विधि वांछित वर्ग का ऑब्जेक्ट बनाता है, डिफ़ॉल्ट रूप से क्लास टी का ऑब्जेक्ट बनाया जाता है।
उपज विधि स्वीकृत मूल्य के आधार पर एक वस्तु बनाती है। इस पद्धति का उद्देश्य बाद में वर्णित किया जाएगा।
प्रतिलिपि विधि कक्षा की गहरी प्रतिलिपि बनाती है। यह ध्यान देने योग्य है कि नकल के लिए, आपको पैरामीटर के रूप में वर्ग के वास्तविक उदाहरण के प्रकार को निर्दिष्ट करना होगा, आधार प्रकार उपयुक्त नहीं है।

इस मामले में, सिंगलटन को फिर से लिखा जाएगा:

 template<typename T> struct AnAutoCreate : An<T> { AnAutoCreate() { create(); } }; template<typename T> T& single() { static T t; return t; } template<typename T> An<T> anSingle() { return single<AnAutoCreate<T>>(); }

हेल्पर मैक्रोज़ इस तरह होंगे:

 #define PROTO_IFACE(D_iface, D_an) \ template<> void anFill<D_iface>(An<D_iface>& D_an) #define DECLARE_IMPL(D_iface) \ PROTO_IFACE(D_iface, a); #define BIND_TO_IMPL(D_iface, D_impl) \ PROTO_IFACE(D_iface, a) { a.create<D_impl>(); } #define BIND_TO_SELF(D_impl) \ BIND_TO_IMPL(D_impl, D_impl) #define BIND_TO_IMPL_SINGLE(D_iface, D_impl) \ PROTO_IFACE(D_iface, a) { a = anSingle<D_impl>(); } #define BIND_TO_SELF_SINGLE(D_impl) \ BIND_TO_IMPL_SINGLE(D_impl, D_impl) #define BIND_TO_IFACE(D_iface, D_ifaceFrom) \ PROTO_IFACE(D_iface, a) { anFill<D_ifaceFrom>(a); } #define BIND_TO_PROTOTYPE(D_iface, D_prototype) \ PROTO_IFACE(D_iface, a) { a.copy(anSingle<D_prototype>()); }

BIND_TO_IMPL_SINGLE मैक्रो में छोटे परिवर्तन हुए हैं, जो अब एकल फ़ंक्शन के बजाय aSingle फ़ंक्शन का उपयोग करता है, जो बदले में, An के पहले से भरे इंस्टेंस को लौटाता है। मैं बाद में अन्य मैक्रों के बारे में बात करूंगा।

सिंगलटन का उपयोग करना

अब, एकल वर्ग को लागू करने के लिए वर्णित वर्ग का उपयोग करने पर विचार करें:

 // header file struct X { X() { x = 1; } int x; }; //    DECLARE_IMPL(X) // cpp file struct Y : X { Y() { x = 2; } int y; }; //   X   Y   BIND_TO_IMPL_SINGLE(X, Y)

अब इसे निम्नानुसार इस्तेमाल किया जा सकता है:

 An<X> x; std::cout << x->x << std::endl;

स्क्रीन पर वह नंबर 2 देगा, क्योंकि कार्यान्वयन के लिए, क्लास वाई का उपयोग किया गया था।

जीवन समय नियंत्रण

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

 struct A { A() { std::cout << "A" << std::endl; a = 1; } ~A() { std::cout << "~A" << std::endl; a = -1; } int a; }; struct B { B() { std::cout << "B" << std::endl; } ~B() { std::cout << "~B" << std::endl; out(); } void out() { std::cout << single<A>().a << std::endl; } };

अब देखते हैं कि इस कॉल को आउट फंक्शन में क्या प्रदर्शित किया जाता है:

 single<B>().out(); //    B A 1 ~A ~B -1

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

आइए अब देखें कि आप ऐसा कैसे कर सकते हैं, लेकिन वस्तुओं के जीवनकाल पर नियंत्रण के साथ। ऐसा करने के लिए, हम अपनी कक्षा का उपयोग करेंगे:

 struct A { A() { std::cout << "A" << std::endl; a = 1; } ~A() { std::cout << "~A" << std::endl; a = -1; } int a; }; //   A      BIND_TO_SELF_SINGLE(A) struct B { An<A> a; B() { std::cout << "B" << std::endl; } ~B() { std::cout << "~B" << std::endl; out(); } void out() { std::cout << a->a << std::endl; } }; //   B      BIND_TO_SELF_SINGLE(B) //  An<B> b; b->out();

निम्नलिखित महत्वपूर्ण विवरणों को छोड़कर, यह कोड व्यावहारिक रूप से पिछले एक से अलग नहीं है:

ऑब्जेक्ट A और B एकल वर्ग के लिए एक वर्ग का उपयोग करते हैं।
कक्षा बी स्पष्ट रूप से वर्ग ए के संबंधित सार्वजनिक सदस्य का उपयोग करके कक्षा ए पर निर्भरता की घोषणा करता है (इस दृष्टिकोण पर अधिक पिछले लेख में पाया जा सकता है)।

आइए देखें कि अब स्क्रीन पर क्या प्रदर्शित होता है:

 B A 1 ~B 1 ~A

जैसा कि आप देख सकते हैं, अब हमने कक्षा ए के जीवन को बढ़ाया है और वस्तुओं के विनाश के क्रम को बदल दिया है। -1 की अनुपस्थिति का अर्थ है कि वस्तु अपने डेटा तक पहुंच के दौरान मौजूद थी।

कुल मिलाकर

इस पर, वस्तुओं के जीवनकाल के लिए समर्पित लेख का पहला भाग समाप्त हो गया। अगले भाग (या भागों) में, विकसित कार्यक्षमता का उपयोग करते हुए शेष जेनेरिक डिज़ाइन पैटर्न का विश्लेषण किया जाएगा और सामान्य निष्कर्ष निकाले जाएंगे।

पुनश्च

कई लोग पूछते हैं, और वास्तव में, क्या बात है? आप सिर्फ एक सिंगलटन क्यों नहीं बना सकते? कुछ अतिरिक्त निर्माणों का उपयोग क्यों करें जो स्पष्टता नहीं जोड़ते हैं, लेकिन केवल कोड को जटिल करते हैं। सिद्धांत रूप में, पहले लेख [0] को सावधानीपूर्वक पढ़ने के साथ, कोई पहले ही समझ सकता है कि यह दृष्टिकोण अधिक लचीला है और कई सिंगलटन की महत्वपूर्ण कमियों को समाप्त करता है। अगले लेख में यह स्पष्ट रूप से समझा जाएगा कि मैंने इसे इस तरह क्यों चित्रित किया, क्योंकि यह पहले से ही केवल सिंगलटन के बारे में बात नहीं करेगा। और लेख के माध्यम से यह स्पष्ट रूप से स्पष्ट होगा कि सिंगलटन का इससे कोई लेना-देना नहीं है। मैं जो दिखाने की कोशिश कर रहा हूं वह सब निर्भरता के उलटा सिद्धांत [4] का उपयोग है ( ओड के सिद्धांतों को भी देखें [5] )। वास्तव में, यह पहली बार था जब मैंने जावा में इस दृष्टिकोण को देखा था कि मैं नाराज था कि यह C ++ में खराब उपयोग किया जाता है (सिद्धांत रूप में, ऐसी रूपरेखाएं हैं जो समान कार्यक्षमता प्रदान करती हैं, लेकिन मैं कुछ और अधिक हल्के और व्यावहारिक चाहूंगा)। उपरोक्त कार्यान्वयन इस दिशा में सिर्फ एक छोटा कदम है, जो पहले से ही बहुत लाभकारी है।

मैं कुछ और बातों पर भी ध्यान देना चाहूंगा, जो दिए गए कार्यान्वयन को क्लासिक सिंगलटन से अलग करती हैं (आमतौर पर बोलना, ये परिणाम हैं, लेकिन वे महत्वपूर्ण हैं):

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

अद्यतन

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

 struct IDatabase { virtual ~IDatabase() {} virtual void beginTransaction() = 0; virtual void commit() = 0; ... };

हमारे पास एक वर्ग है जो आवश्यक उपयोगकर्ता सहित हमें आवश्यक जानकारी प्रदान करता है:

 struct UserManager { An<IDatabase> aDatabase; User getUser(int userId) { aDatabase->beginTransaction(); ... } };

यहाँ हम aDatabase सदस्य बनाते हैं जो कहता है कि उसे किसी प्रकार के डेटाबेस की आवश्यकता है उसके लिए यह जानना महत्वपूर्ण नहीं है कि यह किस तरह का डेटाबेस होगा, उसे यह जानने की जरूरत नहीं है कि यह कौन और कब भरेगा / भरेगा। लेकिन UserManager वर्ग जानता है कि उसे वहां क्या चाहिए। वह कहता है: "मुझे आवश्यक कार्यान्वयन दे दो, मैं नहीं जानता कि कौन सा है, और मैं इस डेटाबेस से आपकी ज़रूरत का हर काम करूँगा, उदाहरण के लिए, मैं इस डेटाबेस से उपयोगकर्ता के बारे में आवश्यक जानकारी प्रदान करूँगा।"

अब हम ट्रिक करते हैं। चूंकि हमारे पास केवल एक डेटाबेस है जिसमें हमारी सभी जानकारी है, हम कहते हैं: ठीक है, चूंकि केवल एक ही डेटाबेस है, चलो एक सिंगलटन बनाते हैं, और इसलिए क्रियान्वयन भरण में हर बार भाप स्नान नहीं करना है, सिंगलटन को स्वयं भरें :

 struct MyDatabase : IDatabase { virtual void beginTransaction(); ... }; BIND_TO_IMPL_SINGLE(IDatabase, MyDatabase)

यानी हम MyDatabase का कार्यान्वयन बनाते हैं और कहते हैं कि हम इसे BIND_TO_IMPL_SINGLE मैक्रो का उपयोग करके सिंगलटन के लिए उपयोग करेंगे। फिर निम्न कोड स्वचालित रूप से MyDatabase का उपयोग करेगा:

 UserManager manager; User user = manager.getUser(userId);

समय के साथ, यह पता चला कि हमारे पास एक और डेटाबेस है, जिसमें उपयोगकर्ता भी हैं, लेकिन, कहते हैं, दूसरे संगठन के लिए:

 struct AnotherDatabase : IDatabase { ... };

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

 UserManager manager; manager.aDatabase = anSingle<AnotherDatabase>(); User user = manager.getUser(userId);

और जैसे कि जादू से, अब हम उपयोगकर्ता को दूसरे डेटाबेस से लेते हैं! यह एक नहीं बल्कि क्रूड उदाहरण है, लेकिन यह स्पष्ट रूप से निर्भरता से निपटने के सिद्धांत को दर्शाता है: यह तब होता है जब एक IDATabase कार्यान्वयन पारंपरिक दृष्टिकोण के बजाय एक UserManager के साथ भर जाता है, जब UserManager स्वयं आवश्यक कार्यान्वयन की खोज करता है। इस आलेख में, इस सिद्धांत का उपयोग किया जाता है, जबकि कार्यान्वयन के लिए एक सिंगलटन को एक विशेष मामले के रूप में लिया जाता है।

साहित्य

सिंग्लटन पैटर्न का उपयोग करना
[१] विकिपीडिया: सिंगलटन
[२] इनसाइड C ++: सिंगलटन
[३] जनरेटिंग पैटर्न: सिंगलटन
[४] निर्भरता का उलटा सिद्धांत
[५] OOD के सिद्धांत
[६] विकिपीडिया: संदर्भ और गति शब्दार्थ

सिंगलटन और ऑब्जेक्ट लाइफटाइम