सिंगलेट्स परीक्षण और सबक्लासिंग

Question

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

लेकिन अगर आपको इसकी ज़रूरत है, तो परीक्षण और सबक्लासिंग मुद्दे के लिए कोई कामकाज है?

Answer 1

सिंगलेट्स का परीक्षण करना मुश्किल बनाता है कोड उनके सिंगलटन-नेस को लागू करता है (जिसका मतलब public static MySingleton getInstance() {...} बॉयलरप्लेट) है। एक व्युत्क्रम के- नियंत्रण कंटेनर का उपयोग करना, Picocontainer या Guice या स्प्रिंग की तरह, उस वस्तु से चिंता समाप्त हो तो अब:

• यह instantiated जा सकता है और है सहयोगियों एक समस्या के बिना परीक्षण में यह में प्लग।

• एक सिंगलटन को कॉल करने वाले कोड को यह नहीं पता होना चाहिए कि यह किस वर्ग को देख रहा है (जिसे यह जानना होगा कि उसे स्थिर विधि कहनी है या नहीं)।

मैं इस तरह के समान होने के नाते पिकोकॉन्टेनर की वेबसाइट पर सलाह की व्याख्या करता हूं। वे आपको क्या बता रहे हैं, हमारे कंटेनर को आपके लिए अपने घटकों का दायरा प्रबंधित करने दें, उनको दायरे-लागू कोड को कठोर न करें।

Answer 2

आप होना आवश्यक है तो एकमात्र:

1. एक अंतरफलक एक वैश्विक/सिंगलटन ServiceLocator
2. स्विच से प्रत्येक सिंगलटन
3. पहुँच अपने एकमात्र का वर्णन है ServiceLocator में पंजीकृत उदाहरणों

परीक्षण के दौरान

उदाहरण:

interface IBankApi 
{ 
    public void MakeDeposity(int accountNumber, int dollarAmount); 
    // ... 
} 

public class RealBankApi : IBankApi { ... } 

// startup code 
serviceLocator.Register<IBankApi>(new RealBankApi()); 

// code using the API 
serviceLocator.Resolve<IBankApi>().MakeDeposit(...); 

// test code setup 
class FakeBankApi : IBankApi { ... } 
serviceLocator.Register<IBankApi>(new FakeBankApi()); 

Answer 3

पहले उपयोग में शुरू किए गए सिंगलेट्स की बजाय आईओसी (नियंत्रण में उलटा) का उपयोग अन्य कारणों से भी फायदेमंद है।

सिंगलटन-प्रारंभिकरण बहु-थ्रेडिंग मुद्दों से (प्रसिद्ध रूप से) पीड़ित हो सकता है जहां दो धागे इसे पहली बार एक्सेस करने का प्रयास करते हैं। बाद में पहुंच सही ढंग से सिंकोनिज्ड होने की संभावना है लेकिन पहले व्यक्ति को करना बहुत मुश्किल है।

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

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

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