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

परिचय

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

यदि आप इस विषय पर साहित्य पढ़ते हैं, तो आप इस दृष्टिकोण की विभिन्न आलोचनाओं में आ सकते हैं। यहाँ नुकसान की एक सूची है :

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

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

कार्यान्वयन

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

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

एक विचार है, इसे C ++ में लागू करें। यहां, टेम्पलेट्स और उनकी विशेषज्ञता की संभावना हमें मदद करेगी। सबसे पहले, हम एक ऐसे वर्ग को परिभाषित करते हैं जिसमें आवश्यक उदाहरण के लिए एक पॉइंटर होगा:

template<typename T> struct An { An() { clear(); } T* operator->() { return get0(); } const T* operator->() const { return get0(); } void operator=(T* t) { data = t; } bool isEmpty() const { return data == 0; } void clear() { data = 0; } void init() { if (isEmpty()) reinit(); } void reinit() { anFill(*this); } private: T* get0() const { const_cast<An*>(this)->init(); return data; } T* data; }; 

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

 template<typename T> void anFill(An<T>& a) { throw std::runtime_error(std::string("Cannot find implementation for interface: ") + typeid(T).name()); } 

इस प्रकार, डिफ़ॉल्ट रूप से, यह फ़ंक्शन अघोषित फ़ंक्शन के उपयोग को रोकने के लिए एक अपवाद फेंकता है।

उपयोग के उदाहरण

अब मान लें कि हमारे पास एक वर्ग है:

 struct X { X() : counter(0) {} void action() { std::cout << ++ counter << ": in action" << std::endl; } int counter; }; 

हम इसे विभिन्न संदर्भों में उपयोग के लिए एक सिंगलटन बनाना चाहते हैं। ऐसा करने के लिए, हम अपनी कक्षा X के लिए एफ़िल फ़ंक्शन के विशेषज्ञ हैं:

 template<> void anFill<X>(An<X>& a) { static X x; a = &x; } 

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

 An<X> x; x->action(); 

या आसान:

 An<X>()->action(); 

क्या प्रदर्शित करेगा:

 1: in action 

जब कार्रवाई फिर से बुलाई जाएगी, तो हम देखेंगे:

 2: in action 

जिसका अर्थ है कि हमारे पास अभी भी राज्य है और दसवीं कक्षा का उदाहरण बिल्कुल एक है। अब उदाहरण को थोड़ा जटिल करते हैं। ऐसा करने के लिए, एक नया वर्ग Y बनाएं जिसमें दसवीं कक्षा का उपयोग होगा:

 struct Y { An<X> x; void doAction() { x->action(); } }; 

अब यदि हम डिफ़ॉल्ट उदाहरण का उपयोग करना चाहते हैं, तो हम बस निम्नलिखित कर सकते हैं:

 Y y; y.doAction(); 

पिछली कॉल के बाद क्या प्रदर्शित होगा:

 3: in action 

अब मान लीजिए कि हम कक्षा के एक और उदाहरण का उपयोग करना चाहते थे। यह करना बहुत आसान है:

 X x; yx = &x; y.doAction(); 

यानी हम अपने (ज्ञात) उदाहरण के साथ वर्ग Y को पॉप्युलेट करते हैं और संबंधित फ़ंक्शन को कॉल करते हैं। स्क्रीन पर हमें:

 1: in action 

अब हम एब्स्ट्रैक्शन इंटरफेस के मामले की जांच करते हैं। एक सार आधार वर्ग बनाएँ:

 struct I { virtual ~I() {} virtual void action() = 0; }; 

इस इंटरफ़ेस के 2 अलग-अलग कार्यान्वयनों को परिभाषित करें:

 struct Impl1 : I { virtual void action() { std::cout << "in Impl1" << std::endl; } }; struct Impl2 : I { virtual void action() { std::cout << "in Impl2" << std::endl; } }; 

डिफ़ॉल्ट रूप से, हम Impl1 के पहले कार्यान्वयन का उपयोग करके पॉपुलेट करेंगे:

 template<> void anFill<I>(An<I>& a) { static Impl1 i; a = &i; } 

तो निम्नलिखित कोड:

 An<I> i; i->action(); 

निष्कर्ष देगा:

 in Impl1 

हमारे इंटरफ़ेस का उपयोग करके एक क्लास बनाएँ:

 struct Z { An<I> i; void doAction() { i->action(); } }; 

अब हम कार्यान्वयन को बदलना चाहते हैं। फिर निम्नलिखित करें:

 Z z; Impl2 i; zi = &i; z.doAction(); 

जिसके परिणामस्वरूप:

 in Impl2 

विचार विकास

सामान्य तौर पर, यह समाप्त हो सकता है। हालाँकि, यह जीवन को आसान बनाने के लिए कुछ उपयोगी मैक्रोज़ जोड़ने के लायक है:

 #define PROTO_IFACE(D_iface) \ template<> void anFill<D_iface>(An<D_iface>& a) #define DECLARE_IMPL(D_iface) \ PROTO_IFACE(D_iface); #define BIND_TO_IMPL_SINGLE(D_iface, D_impl) \ PROTO_IFACE(D_iface) { a = &single<D_impl>(); } #define BIND_TO_SELF_SINGLE(D_impl) \ BIND_TO_IMPL_SINGLE(D_impl, D_impl) 

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

DECLARE_IMPL मैक्रो डिफ़ॉल्ट पैडिंग के अलावा एक पैडिंग की घोषणा करता है। वास्तव में, यह रेखा कहती है कि इस वर्ग के लिए स्पष्ट आरंभीकरण के अभाव में एक निश्चित मूल्य के साथ एक स्वचालित भरना होगा। कार्यान्वयन के लिए मैक्रो BIND_TO_IMPL_SINGLE का उपयोग CPP फ़ाइल में किया जाएगा। यह एकल फ़ंक्शन का उपयोग करता है, जो एकल उदाहरण देता है:

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

मैक्रो BIND_TO_SELF_SINGLE का उपयोग करने का अर्थ है कि इसका एक उदाहरण कक्षा के लिए उपयोग किया जाएगा। जाहिर है, एक अमूर्त वर्ग के मामले में यह मैक्रो लागू नहीं है और वर्ग कार्यान्वयन के विनिर्देश के साथ BIND_TO_IMPL_SINGLE का उपयोग करना आवश्यक है। यह कार्यान्वयन केवल CPP फ़ाइल में छिपाया और घोषित किया जा सकता है।

अब एक विशिष्ट उदाहरण के उपयोग पर विचार करें, उदाहरण के लिए, कॉन्फ़िगरेशन:

 // IConfiguration.hpp struct IConfiguration { virtual ~IConfiguration() {} virtual int getConnectionsLimit() = 0; virtual void setConnectionLimit(int limit) = 0; virtual std::string getUserName() = 0; virtual void setUserName(const std::string& name) = 0; }; DECLARE_IMPL(IConfiguration) // Configuration.cpp struct Configuration : IConfiguration { Configuration() : m_connectionLimit(0) {} virtual int getConnectionsLimit() { return m_connectionLimit; } virtual void setConnectionLimit(int limit) { m_connectionLimit = limit; } virtual std::string getUserName() { return m_userName; } virtual void setUserName(const std::string& name) { m_userName = name; } private: int m_connectionLimit; std::string m_userName; }; BIND_TO_IMPL_SINGLE(IConfiguration, Configuration); 

आगे इसे अन्य वर्गों में उपयोग किया जा सकता है:

 struct ConnectionManager { An<IConfiguration> conf; void connect() { if (m_connectionCount == conf->getConnectionsLimit()) throw std::runtime_error("Number of connections exceeds the limit"); ... } private: int m_connectionCount; }; 

निष्कर्ष

परिणामस्वरूप, मैं निम्नलिखित बातों पर ध्यान दूंगा:

1. इंटरफ़ेस निर्भरता की स्पष्ट परिभाषा: अब आपको निर्भरता देखने की ज़रूरत नहीं है, वे सभी वर्ग घोषणा में लिखे गए हैं और यह इसके इंटरफ़ेस का हिस्सा है।
2. एक एकल उदाहरण और वर्ग इंटरफ़ेस तक पहुँच प्रदान करना अलग-अलग वस्तुओं में अलग किया जाता है। इस प्रकार, हर कोई अपनी समस्या को हल करता है, जिससे एसआरपी का संरक्षण होता है।
3. यदि कई कॉन्फ़िगरेशन हैं, तो आप बिना किसी समस्या के कनेक्शन मैनजर वर्ग में आवश्यक उदाहरण आसानी से भर सकते हैं।
4. क्लास की टेस्टिबिलिटी: आप मॉक ऑब्जेक्ट बना सकते हैं और चेक कर सकते हैं, उदाहरण के लिए, जब आप कनेक्ट विधि को कॉल करते हैं, तो स्थिति सही ढंग से काम करती है:
   

    struct MockConfiguration : IConfiguration { virtual int getConnectionsLimit() { return 10; } virtual void setConnectionLimit(int limit) { throw std::runtime_error("not implemented in mock"); } virtual std::string getUserName() { throw std::runtime_error("not implemented in mock"); } virtual void setUserName(const std::string& name) { throw std::runtime_error("not implemented in mock"); } }; void test() { // preparing ConnectionManager manager; MockConfiguration mock; manager.conf = &mock; // testing try { manager.connect(); } catch(std::runtime_error& e) { //... } } 

   
   

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

साहित्य

[१] आरएसडीएन फोरम: सिंगलटन दोष सूची
[२] विकिपीडिया: सिंगलटन
[३] इनसाइड C ++: सिंगलटन