निरंतर इंटरफेस के लिए सबसे अधिक अनुकूल विकल्प क्या हैं?

मैं ऑफ-किनारे समूह द्वारा विकसित कुछ कोड देख रहा था। मैं परिभाषित प्रति मॉड्यूल कम से कम एक "निरंतर इंटरफ़ेस" देखते हैं। उदाहरण (नहीं असली दुनिया):निरंतर इंटरफेस के लिए सबसे अधिक अनुकूल विकल्प क्या हैं?

public interface RequestConstants{ 
    //a mix of different constants(int,string,...) 
    public static final int MAX_REQUESTS = 9999; 
    public static final String SAMPLE_REQUEST = "Sample Request"; 
}

मेरी समझ के अनुसार यह इन चलाने के समय में किसी भी उपयोगिता नहीं करता है, और बचा या एक अलग तरीके से घेरने की कोशिश की जानी चाहिए के रूप में एक विरोधी पैटर्न है। इसका प्रतिनिधित्व करने के सुरुचिपूर्ण तरीके क्या हैं? enums इसके बजाए उपयोग किया जा सकता है?

स्रोत

2011-09-15 ring bearer

वाह! नीचे वोट। लेकिन क्यों? –

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

एन enum शायद एक अच्छा विचार है, जब तक कि सभी मापदंडों को बारीकी से संबंधित हैं नहीं है। आपके उदाहरण में दो पैरामीटर के साथ मैं कहूंगा कि वे एक enum के रूप में अर्हता प्राप्त करने के लिए पर्याप्त निकटता से संबंधित नहीं हैं।

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

जब तक आप उस पथ नीचे जा के बारे में सोच रहे हैं, हालांकि, मैं कहना चाहता हूँ कक्षाएं जहां संबंधित मानकों को उपयोग किया जाता है में स्थिर फाइनल, जाने के लिए रास्ता नहीं है के रूप में पहले से ही सुझाव दिया गया है।

स्रोत

2011-09-15 19:59:41 Uffe

मैं सहमत हूं। इंटरफेस के बजाय enums और कक्षाओं का उपयोग मौजूदा कोड तोड़ सकता है। मैं इसे एक विरोधी पैटर्न के गंभीर के रूप में नहीं देखता हूं। – emory

एक private निर्माता के साथ एक final वर्ग में इंटरफेस बारी

।

स्रोत

2011-09-15 19:49:24 nfechner

यह अच्छा होगा ... –

मैं कक्षा जहां वे वे सबसे अधिक प्रासंगिक हैं बनाने में स्थिरांक डाल करने के लिए पसंद करते हैं, और फिर अगर मैं कहीं और उन्हें का उल्लेख करने केहै, बस ऐसा - स्थिर आयात का उपयोग कर कि अगर समझ में आता है संभवतः (जैसे Math.PI के लिए)।

इंटरफेस में स्थिरांक डाल करने के लिए केवल असली कारण आप विधि से मुक्त इंटरफेस "लागू" और किसी भी आगे योग्यता के बिना अपने साधारण नाम के माध्यम से स्थिरांक तक पहुँच प्राप्त करने की अनुमति थी। स्थिर आयात उस कारण को हटा दें।

स्रोत

2011-09-15 19:49:25

स्थिर आयात वास्तव में कुछ परिस्थितियों में वांछित प्रभाव प्राप्त नहीं करते हैं। यदि मेरे पास .java फ़ाइल (उदा। नेस्टेड फाइलें) में एकाधिक कक्षाएं हैं, तो प्रत्येक वर्ग में स्वयं का स्थिरांक सेट हो सकता है और उनमें से कुछ को ओवरलैपिंग नाम हो सकते हैं। एक स्थिर आयात का उपयोग एक संघर्ष का मतलब होगा। – emory

@emory: सच है। दूसरी तरफ, मैं उस मामले में इंटरफ़ेस चाल का उपयोग नहीं करना चाहूंगा - वही निरंतर नाम होने का अर्थ है कि एक ही फ़ाइल में अलग-अलग चीजें मेरे लिए एक बुरा विचार है। –

@ जोन स्कीट - "इंटरफेस में स्थिरांक रखने का एकमात्र असली कारण आपको विधि मुक्त इंटरफेस को" कार्यान्वित "करने और उनके सरल नामों के माध्यम से स्थिरांक तक पहुंचने की अनुमति देना था" - बहुत दिलचस्प लगता है। लेकिन क्या यह ओओ स्टैंड प्वाइंट से एक बुरा अभ्यास नहीं है - यह वास्तविक दुनिया में कैसे संबंधित है? - आपके उत्तर के लिए धन्यवाद। –

उपयोग अंतिम गैर instantiable वर्ग है, यानी एक निजी निर्माता के साथ एक।

स्रोत

2011-09-15 19:49:45

... यदि इन उत्तरों पर डाउनवॉट समझाया गया था। –

निरंतर इंटरफेस के लिए सबसे अधिक अनुकूल विकल्प क्या हैं?

उत्तर

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