सभी कक्षाओं में कॉन्फ़िगरेशन उपलब्ध कराने के लिए

Question

मैं एक छोटा वेब सर्वर लिख रहा हूं, और यह विभिन्न विकल्पों के सभी प्रकार के साथ कॉन्फ़िगरेशन फ़ाइल लेता है: कितने थ्रेड चलाने के लिए, कौन सा वर्ग प्रत्येक फ़ाइल एक्सटेंशन को प्रदर्शित करता है, जो फ़ाइल प्रदर्शित करने के लिए डिफ़ॉल्ट रूप से और इतने पर और आगे। इसका प्रतिनिधित्व करने के लिए, मैं कॉन्फ़िगरेशन फ़ाइल को Configuration ऑब्जेक्ट में पार्स कर रहा हूं जिसमें इन सभी सेटिंग्स शामिल हैं, और मुख्य श्रेणी में यह ऑब्जेक्ट है।
हालांकि, कॉन्फ़िगरेशन डेटा सर्वर के लगभग हर स्तर पर आवश्यक है - कक्षाओं के भीतर कक्षाओं के भीतर कक्षाएं ...

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

Answer 1

मैं निश्चित रूप से विन्यास धारक वर्ग को सिंगलटन बना दूंगा! मैं सिंगलटन उदाहरण के लिए शास्त्रीय उपयोग केस है।

Answer 2

इसे सिंगलटन बनाना एक उचित समाधान की तरह लगता है। मुझे लगता है कि कॉन्फ़िगरेशन को अन्य क्लास कन्स्ट्रक्टर या विधि कॉल के पैरामीटर के रूप में पास करने की गलती होगी क्योंकि यह विधि तर्कों को प्रदूषित करेगा और उन्हें अनावश्यक रूप से जटिल बना देगा।

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

Answer 3

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

public enum Config{ DATA; 

    private int value1; 
    private int value2; 
    private int value3; 
    public load(File configFile) { 
    // some magic to store the values 
    } 
    public int getValue1() {return value1;} 
    public int getValue2() {return value2;} 
    public int getValue3() {return value3;} 
} 

अपने कोड में हर जगह इसका इस्तेमाल कर सकते हैं::

आप सिंगलटन के लिए जाते हैं, तो enum पैटर्न लागू करने पर विचार

int property = Config.DATA.getValue1(); 

Answer 4

आप, मैं होता जावा में यह कर रहे हैं Spring में सभी कॉन्फ़िगरेशन रखें और फिर सेटिंग देखने के लिए Application Context का उपयोग करें या बस उन्हें अपने सेम में इंजेक्ट करें। वसंत इस तरह की चीज पर उत्कृष्टता प्राप्त करता है।

Answer 5

हमारे पास आपके गुण सिस्टम गुण के रूप में सेट हैं। इन्हें SystemProperties कक्षा द्वारा एक्सेस किया जाता है।
यह वर्ग final एक निजी कन्स्ट्रक्टर के साथ है, गुणों को केवल स्थिर विधियों के माध्यम से उपयोग किया जाता है, इसलिए यह तकनीकी रूप से सिंगलटन है। यह स्वयं एक commons.jar में निहित है हर दूसरे परियोजना के आधार पर है।

इसलिए कुछ भी पास करने की आवश्यकता नहीं है क्योंकि सेटिंग्स सीधे उपलब्ध हैं जहां आपको उनकी आवश्यकता है।

Answer 6

Guice का उपयोग करें! गुइस एक निर्भरता-इंजेक्शन ढांचा है जो प्रभावी रूप से नए कीवर्ड के उपयोग को प्रतिस्थापित करता है। , Newing के बजाय ऊपर सीधे

और फिर WebServer, तो आप सिर्फ यह तुम्हारे लिए क्या करने के लिए Guice से पूछते हैं:: आप अपने वस्तु बाइंडिंग एक मॉड्यूल में इस तरह परिभाषित

WebServer ws = Guice.createInjector(yourModule).getInstance(WebServer.class); 

कौन सा जादुई MySpecificWebServerImplementation पैदा करेगा तुम्हारे लिए।इस प्रकार यदि MySpecificWebServerImplementation परिभाषित किया गया है:

public class MySpecificWebServerImplementation { 
    @Inject 
    public MySpecificWebServerImplementation(Configuration configuration) { 
    } 
} 

फिर MySpecificWebServerImplementation स्वचालित रूप से विन्यास के आधार पर प्राप्त होगा और आप इसे चारों ओर से गुजर रहा बारे में चिंता करने की जरूरत नहीं है।

Answer 7

कॉन्फ़िगरेशन नहीं, लेकिन यह एक सिंगलटन ऑब्जेक्ट ServerManager होना अच्छा है। बहुत अधिक वैश्विक रूप से सुलभ वस्तुओं को थोड़ा उलझन में हैं। विन्यास "घटक" के स्वामित्व से करना चाहिए:

ServerManager.getServerManager.getConfigurationComponent(Configuration.class); 

ServerManager बना सकते हैं और शुरू करने का समय पर विन्यास वस्तु पढ़ना चाहिए। छोड़ने से पहले इसे सहेजें और बंद करें।

यदि आप किसी भी कक्षा में इसे एक से अधिक बार निजी फाइनल फील्ड के रूप में उपयोग करते हैं।

Answer 8

हालांकि Singletons को कई कारणों से कई पेशेवरों द्वारा पसंद नहीं किया जाता है - मुझे लगता है कि एससिंगटन का उपयोग करने के लिए अभी भी एक अच्छा उपयोग मामला है।

हालांकि - खुद से पूछें कि क्या वेबसर्वर की आवश्यकताओं को सर्वर के सभी पहलुओं के लिए वास्तव में एक सामान्य कॉन्फ़िगरेशन की आवश्यकता है। और यदि हां - जल्द ही उन्हें बदलने की संभावना कितनी है? उदाहरण के लिए - मान लें कि आपका सर्वर 3 वेब साइट होस्ट करता है। और अब आप में से एक पर बैंडविड्थ सीमाएं डालने के लिए कहा जाता है - आप इसे कैसे कॉन्फ़िगर करेंगे?

मैं वास्तव में एक अच्छा सिंगलटन का पक्ष लेता हूं - हालांकि आपको बहु थ्रेड वाले वातावरण में प्रारंभ करते समय पूरे थ्रेड-सुरक्षा समस्या को ध्यान में रखना होगा (हालांकि ऐसा लगता है कि आपको यह समस्या नहीं होगी क्योंकि आपके पास एकाधिक नहीं होंगे धागे। यह आरंभ से पहले

ध्यान रखें एकमात्र एक ClassLoader के भीतर रहते हैं और (आप लोड प्रत्येक .war के लिए उदाहरण के लिए) यदि आप कई ClassLoader रों है कि आप इस "Singleton" की कई प्रतियां होगा।

सभी पर विचार करें आपके सर्वर के पहलुओं, और यदि यह वास्तव में सरल है - Singleton sav ई आप बहुत सिरदर्द - और कोड को और अधिक रखरखाव और पठनीय बना देगा। जैसा कि पहले से ही एक या दो उत्तरों में उल्लिखित है - निर्भरता इंजेक्शन Singleton के लिए एक अच्छा विकल्प है - वे आपको अपने जुनीट को आसान बनाने में मदद करते हैं। JUnit के बारे में

एक टिप्पणी, मैं समझता हूँ (यह अभी तक की कोशिश नहीं की) है कि Mockit आप अभी भी विभिन्न परिदृश्यों के लिए अलग JUnit परीक्षण मामलों बना सकते हैं, एक परीक्षण चलाने के दौरान एक वास्तविक क्रियान्वयन को बदलने के लिए अनुमति दे सकते हैं अपने Singleton को संशोधित किए बिना टेस्ट करने योग्य होना