लोग इसका उपयोग क्यों करते हैं?
मैंने पीएचपी दुनिया में काफी संख्या में सिंगलटन देखे हैं। मुझे ऐसा कोई उपयोग मामला याद नहीं है, जहाँ मुझे पैटर्न का औचित्य मिला हो। लेकिन मुझे लगता है कि मुझे प्रेरणा के बारे में एक विचार मिला कि लोगों ने इसका उपयोग क्यों किया।
एकल उदाहरण ।
"पूरे आवेदन में कक्षा सी के एकल उदाहरण का उपयोग करें।"
यह "डिफ़ॉल्ट डेटाबेस कनेक्शन" के लिए एक उचित आवश्यकता है। इसका मतलब यह नहीं है कि आप कभी भी दूसरा db कनेक्शन नहीं बनाएंगे, इसका मतलब यह है कि आप आमतौर पर डिफ़ॉल्ट के साथ काम करते हैं।
एकल तात्कालिकता ।
"कक्षा सी को एक से अधिक बार (प्रक्रिया के अनुसार, अनुरोध, आदि) की अनुमति न दें।"
यह केवल तभी प्रासंगिक है जब कक्षा को तत्काल करने से साइड इफेक्ट होंगे जो अन्य उदाहरणों के साथ संघर्ष करते हैं।
अक्सर इन संघर्षों को घटक को फिर से डिज़ाइन करने से बचा जा सकता है - जैसे कि क्लास कंस्ट्रक्टर से साइड इफेक्ट्स को समाप्त करके। या उन्हें अन्य तरीकों से हल किया जा सकता है। लेकिन अभी भी कुछ कानूनी उपयोग के मामले हो सकते हैं।
आपको इस बारे में भी सोचना चाहिए कि क्या "केवल एक" आवश्यकता का अर्थ "एक प्रति प्रक्रिया" है। उदाहरण के लिए, संसाधन की समयावधि के लिए, आवश्यकता "प्रति संपूर्ण प्रणाली, प्रक्रियाओं में एक" और "एक प्रति प्रक्रिया" नहीं है। और अन्य चीजों के लिए यह "अनुप्रयोग संदर्भ" के अनुसार है, और आप बस प्रति प्रक्रिया एक आवेदन संदर्भ होना चाहिए।
अन्यथा, इस धारणा को लागू करने की कोई आवश्यकता नहीं है। इसे लागू करने का अर्थ यह भी है कि आप इकाई परीक्षणों के लिए एक अलग उदाहरण नहीं बना सकते हैं।
वैश्विक पहुंच।
यह केवल तभी वैध है जब आपके पास उन ऑब्जेक्ट्स को पास करने के लिए कोई उचित बुनियादी ढांचा नहीं है, जहां उनका उपयोग किया जाता है। इसका मतलब यह हो सकता है कि आपका ढांचा या वातावरण बेकार है, लेकिन इसे ठीक करने के लिए आपकी शक्तियों के भीतर नहीं हो सकता है।
कीमत तंग युग्मन, छिपी निर्भरता और वैश्विक राज्य के बारे में सब कुछ खराब है। लेकिन आप शायद ये पहले से ही भुगत रहे हैं।
आलसी तात्कालिकता।
यह एक सिंगलटन का आवश्यक हिस्सा नहीं है, लेकिन यह उन्हें लागू करने का सबसे लोकप्रिय तरीका लगता है। लेकिन, जबकि आलसी तात्कालिकता के लिए एक अच्छी बात है, आपको इसे प्राप्त करने के लिए वास्तव में एक सिंगलटन की आवश्यकता नहीं है।
विशिष्ट कार्यान्वयन
विशिष्ट कार्यान्वयन एक निजी कंस्ट्रक्टर के साथ एक वर्ग है, और एक स्थैतिक उदाहरण चर, और एक स्थिर getInstance () आलसी मध्यस्थता के साथ विधि है।
ऊपर वर्णित समस्याओं के अलावा, यह एकल जिम्मेदारी सिद्धांत के साथ काटता है , क्योंकि वर्ग अपने स्वयं के तात्कालिकता और जीवन चक्र को नियंत्रित करता है , अन्य जिम्मेदारियों के अलावा जो कक्षा पहले से ही है।
निष्कर्ष
कई मामलों में, आप एक सिंगलटन के बिना और वैश्विक राज्य के बिना एक ही परिणाम प्राप्त कर सकते हैं। इसके बजाय, आपको निर्भरता इंजेक्शन का उपयोग करना चाहिए, और आप एक निर्भरता इंजेक्शन कंटेनर पर विचार करना चाह सकते हैं ।
हालाँकि, ऐसे उपयोग के मामले हैं जहां आपके पास निम्नलिखित वैध आवश्यकताएं शेष हैं:
- एकल उदाहरण (लेकिन एक पल का नहीं)
- वैश्विक पहुंच (क्योंकि आप कांस्य युग के ढांचे के साथ काम कर रहे हैं)
- आलसी तात्कालिकता (क्योंकि यह सिर्फ अच्छा है)
तो, इस मामले में आप क्या कर सकते हैं:
एक सार्वजनिक निर्माण के साथ एक वर्ग सी बनाएं, जिसे आप त्वरित करना चाहते हैं।
एक स्थिर उदाहरण चर और एक स्थिर S :: getInstance () विधि के साथ एक अलग वर्ग एस बनाएं, जो आलसी इंस्टेंटेशन के साथ हो, जो उदाहरण के लिए वर्ग C का उपयोग करेगा।
C. के निर्माण से सभी दुष्प्रभावों को हटा दें। इसके बजाय, इन साइड इफेक्ट्स को S :: getInstance () विधि में डालें।
यदि आपके पास उपरोक्त आवश्यकताओं के साथ एक से अधिक वर्ग हैं, तो आप छोटे स्थानीय सेवा कंटेनर के साथ वर्ग उदाहरणों का प्रबंधन करने के लिए विचार कर सकते हैं , और केवल कंटेनर के लिए स्थिर उदाहरण का उपयोग कर सकते हैं। तो, एस :: getContainer () आपको एक आलसी-त्वरित सेवा कंटेनर देगा, और आपको कंटेनर से अन्य ऑब्जेक्ट मिलते हैं।
जहाँ आप कर सकते हैं स्थिर getInstance () को कॉल करने से बचें। जब भी संभव हो, इसके बजाय निर्भरता इंजेक्शन का उपयोग करें। विशेष रूप से, यदि आप कई वस्तुओं के साथ कंटेनर दृष्टिकोण का उपयोग करते हैं जो एक दूसरे पर निर्भर करते हैं, तो इनमें से किसी को भी S :: getContainer () को कॉल नहीं करना चाहिए।
वैकल्पिक रूप से एक इंटरफ़ेस बनाएं जो वर्ग C को लागू करता है, और इसका उपयोग S :: getInstance () के रिटर्न मान को दस्तावेज़ित करने के लिए करता है।
(क्या हम अभी भी इसे सिंगलटन कहते हैं? मैं इसे टिप्पणी अनुभाग पर छोड़ता हूं ..)
लाभ:
आप किसी भी वैश्विक स्थिति को छूने के बिना, यूनिट परीक्षण के लिए सी का एक अलग उदाहरण बना सकते हैं।
उदाहरण प्रबंधन को वर्ग से ही अलग किया जाता है -> चिंताओं का पृथक्करण, एकल जिम्मेदारी सिद्धांत।
S :: getInstance () उदाहरण के लिए किसी भिन्न वर्ग का उपयोग करना, या गतिशील रूप से यह निर्धारित करना आसान है कि किस वर्ग का उपयोग करना है।