2016-11-30 7 views
6

क्या कक्षा एक सिंगलटन के नीचे सूचीबद्ध है? चूंकि कन्स्ट्रक्टर को सार्वजनिक घोषित किया गया है, क्या मैं अनुमान लगा सकता हूं कि वर्ग गलत कार्यान्वयन वाला सिंगलटन है?क्या यह कक्षा एक सिंगलटन है?

public class CreateDevice extends Functionality{ 

    private static Simulator simulator; 
    ConnectionDB connect = ConnectionDB.getInstance(); 


    public CreateDevice(Simulator simulator){ 
    this.simulator = simulator; 
    } 

    private static CreateDevice instance; 
    synchronized public static CreateDevice getInstance() { 
    if(instance == null){ 
     instance = new CreateDevice(simulator); 
    }  
     return instance; 
    } 
} 
+0

एक वर्ग एक सिंगलटन नहीं हो सकता है, केवल वस्तुएं तब हो सकती हैं जब वे एक तरह से हों। लेकिन कक्षाएं एक ऑब्जेक्ट को तत्कालता प्रतिबंधित करने के लिए सिंगलटन पैटर्न को कार्यान्वित कर सकती हैं :) – zapl

+0

साइड नोट: 'सिम्युलेटर' को 'स्थिर' नहीं होना चाहिए यदि इसे 'CreateDevice' - कन्स्ट्रक्टर में प्रारंभ किया गया है - या तो इसे स्थैतिक बनाएं और इसे वर्गनाम के माध्यम से देखें 'CreateDevice.simulator' या' स्थिर 'कीवर्ड को हटा दें। (हालांकि, वास्तव में सिंगलटन होने के सवाल के साथ कुछ भी नहीं है) – Hulk

+0

आप सही हैं। यह एक समस्याग्रस्त कोड है जिसे संशोधित करने की आवश्यकता है। –

उत्तर

1

आप इसे सिंगलटन बना सकते हैं, लेकिन फिर आपको सिम्युलेटर को इंजेक्ट करने का एक और तरीका ढूंढना होगा।

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

यदि कंटेनर को कम से कम एक बार बुलाया जाने से पहले getInstance() विधि कहा जाता है, तो सिम्युलेटर कभी सेट नहीं होता है।

इसे एक उचित सिंगलटन बनाने के लिए, आप कन्स्ट्रक्टर को हटा सकते हैं और एक निजी नो-Args कन्स्ट्रक्टर जोड़ सकते हैं। आपको एक स्थैतिक सेट सिम्युलेटर() विधि की भी आवश्यकता होगी जो स्थैतिक क्षेत्र सेट करता है, और यह सुनिश्चित कर लें कि सिम्युलेटर के साथ किसी अन्य इंटरैक्शन की आवश्यकता होने से पहले इसे कॉल किया गया हो।

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

+0

आप सही हैं, लेकिन समस्या यह है कि मुझे इसे वास्तविक सिंगलटन में बदलना चाहिए या नहीं। –

+0

यदि आप इसे एक उचित सिंगलटन में बदलते हैं, तो यह वर्तमान स्थिति में सुधार होगा। लेकिन आईओसी का उपयोग करने से भी एक सुधार होगा। – greyfairer

7

एक शब्द में - नहीं। चूंकि कन्स्ट्रक्टर public है, इसलिए कोई भी जब भी और जब भी चाहें इसका एक नया उदाहरण बना सकता है। कन्स्ट्रक्टर private बनाना समस्या को हल करना चाहिए, और कक्षा को सिंगलटन में बदलना चाहिए।

+0

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

2

मैं कहूंगा कि आप यह कहने में सही हैं कि वर्तमान कार्यान्वयन में यह सिंगलटन नहीं होगा।

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

संबंधित मुद्दे