5
या किसी अन्य डिजाइन पैटर्न का उपयोग करना बेहतर है?मैं डुनिट के साथ सिंगलटन क्लास का परीक्षण कैसे कर सकता हूं?
A
उत्तर
13
कुछ दिन पहले here, mocking a Singleton इसी तरह के प्रश्न का उत्तर दिया। मूल पोस्ट सी # के लिए है। एक सिंगलटन के व्यवहार का मज़ाक उड़ाते हुए, लेकिन अभी भी लागू होना चाहिए।
सिंगलटन पैटर्न के संबंध में, इसमें कुछ भी गलत नहीं है - कई मामलों में हम तर्क और डेटा को केंद्रीकृत करना चाहते हैं। हालांकि, सिंगलटन और एक स्थिर वर्ग के बीच बहुत बड़ा अंतर है। अपने सिंगलटन को स्थिर वर्ग हार्ड कोड के रूप में बनाना जो आपके आवेदन में प्रत्येक उपभोक्ता को कार्यान्वित करता है - जो यूनिट परीक्षण को बहुत मुश्किल बनाता है!
आप जो करना चाहते हैं वह आपके सिंगलटन के लिए एक इंटरफ़ेस परिभाषित करता है, जो आपके उपभोक्ताओं के उपयोग के तरीकों का खुलासा करता है। बदले में आपके उपभोक्ता किसी भी कार्यान्वयन वर्ग के संदर्भ में किसी भी व्यक्ति द्वारा तत्काल उन्हें संदर्भित करते हैं [आमतौर पर यह आपका आवेदन है, या एक कंटेनर यदि आप निर्भरता इंजेक्शन \ नियंत्रण में उलझन में हैं)।
यह ढांचा है, जो उपभोक्ताओं को तुरंत चालू कर रहा है, यह सुनिश्चित करने के लिए ज़िम्मेदार है कि एक और केवल एक उदाहरण तैर रहा है। वास्तव में यह नहीं है कि स्थैतिक वर्ग से इंटरफ़ेस संदर्भ [जैसा कि ऊपर दिए गए लिंक में दिखाया गया है] से एक छलांग है, आप केवल विश्व स्तर पर सुलभ उदाहरण की सुविधा खो देते हैं - मुझे पता है कि मुझे पता है, वैश्विक संदर्भ बहुत मोहक हैं, लेकिन ल्यूक ने अपनी पीठ को वापस कर दिया डार्क साइड, तो आप कर सकते हैं!
आम तौर पर, सर्वोत्तम प्रथाएं स्थिर संदर्भों से परहेज करने का सुझाव देती हैं, और इंटरफेस के खिलाफ प्रोजेमिंग को प्रोत्साहित करती हैं। याद रखें, इन बाधाओं के साथ सिंगलटन पैटर्न को लागू करना अभी भी संभव है। इन दिशानिर्देशों का पालन करें, और आपको अपने काम का परीक्षण करने में कोई समस्या इकाई नहीं होनी चाहिए :)
आशा है कि इससे मदद मिलती है!
सिंगलटन! = सार्वजनिक स्थैतिक कक्षा, बल्कि सिंगलटन == एक उदाहरण
1
I'm using the following pattern जब मैं एक स्थिर आधारित एकमात्र कि मैं नकली कर सकते हैं लिखें। कोड जावा है, लेकिन मुझे लगता है कि आपको एक विचार मिलेगा। इस दृष्टिकोण के साथ मुख्य समस्या यह है कि आपको पैकेज-संरक्षित करने के लिए कन्स्ट्रक्टर को आराम करना होगा (जो सॉर्टा एक सच्चे सिंगलटन को हरा देता है)। एक साइड नोट के रूप में - कोड आपके "स्थैतिक" कोड को नकल करने की क्षमता पर लागू होता है, यह आवश्यक नहीं है कि इसे
3
टेस्टेबिलिटी की कमी क्लासिक सिंगलटन मॉडल (एक क्लास क्लास विधि उदाहरण को लौटाने) की प्रमुख गिरावट में से एक है। जहां तक मेरा संबंध है, यह किसी अन्य कोड का उपयोग करने के लिए सिंगलेट्स का उपयोग करने वाले किसी भी कोड को फिर से डिज़ाइन करने के लिए पर्याप्त औचित्य है।
यदि आपको पूरी तरह से एकवचन उदाहरण की आवश्यकता है, तो निर्भरता इंजेक्शन और इंटरफ़ेस को लिखना, जैसा कि जॉनी जी द्वारा सुझाया गया है, निश्चित रूप से जाने का तरीका है।
0
यदि आपको सिंगलटन का उपयोग करना चाहिए (और ऐसा करने के कारण हैं ... लेकिन यदि संभव हो तो मैं हमेशा इसे टालने का प्रयास करता हूं)। मैं इसे प्रबंधित करने के लिए एक आईओसी कंटेनर का उपयोग करने की सलाह दूंगा। मुझे यकीन नहीं है कि डेल्फी के लिए कोई है या नहीं। लेकिन जावा में आप स्प्रिंग का उपयोग कर सकते हैं, .NET में आप विंडसर/कैसल का उपयोग कर सकते हैं। एक आईओसी कंटेनर सिंगलटन पर पकड़ सकता है और परीक्षण के लिए विभिन्न कार्यान्वयन पंजीकृत कर सकता है।
शायद इस स्निपेट से बाहर आने के लिए यह विषय का बहुत बड़ा है।
1
मैं आमतौर पर केवल फ्लाईवेट ऑब्जेक्ट्स या समान मूल्य ऑब्जेक्ट्स के लिए सिंगलेट का उपयोग करता हूं। एक आईओसी कंटेनर (जैसा कि ऊपर चर्चा की गई है) में देखना शायद एक सिंगलटन की तुलना में साझा ऑब्जेक्ट को संभालने का एक बेहतर तरीका है।
पर विचार करें कि स्मालटाक (जहां इन पैटर्न का एक बहुत उत्पन्न), सच और झूठी में दोनों को प्रभावी ढंग से एकमात्र :)
... स्मालटाक के बारे में इस प्रकार थे: हाँ, लेकिन सच है और झूठे _so_ परीक्षण योग्य हैं :) – mjn