क्या स्थिरांक को परिभाषित करने के लिए एक इंटरफ़ेस होना एक बुरा अभ्यास है?


40

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

मेरे द्वारा देखे जाने वाले लाभ इस प्रकार हैं:

  • स्थिरांक तक आसान पहुंच: MY_CONSTANTइसके बजायThatClass.MY_CONSTANT
  • प्रत्येक निरंतर केवल एक बार परिभाषित किया गया

क्या यह दृष्टिकोण एक अच्छा या बुरा अभ्यास है? मुझे ऐसा लगता है कि मैं थोड़ी बहुत इंटरफेस की अवधारणा का दुरुपयोग कर रहा हूं।

आप आम तौर पर इंटरफेस / स्थिरांक के बारे में जवाब दे सकते हैं, लेकिन यूनिट परीक्षणों के बारे में भी अगर इसके बारे में कुछ खास है।


"इंटरफ़ेस डिफाइनर एक्स के लिए" यह एक बुरा अभ्यास है, इसका जवाब एक्स कुछ भी है जो "विधि हस्ताक्षर" नहीं है, लगभग हमेशा "हाँ" है।
टी। सर -

जवाबों:


79

जोशुआ बलोच ने अपनी पुस्तक इफेक्टिव जावा में इसके खिलाफ सलाह दी :

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

आप एक सामान्य वर्ग के साथ एक ही प्रभाव प्राप्त कर सकते हैं जो स्थिरांक को परिभाषित करता है, और फिर उपयोग करता है import static com.example.Constants.*;


13

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

SOMETIMES स्थिरांक कार्यान्वयन विवरण हैं। SOMETIMES वे नहीं हैं। हमेशा की तरह, एक इंजीनियर को अपने मस्तिष्क का उपयोग करने के लिए यह तय करने की आवश्यकता है कि क्या करना है, और एक व्यापक पैटर्न या अभ्यास पर भरोसा नहीं करना चाहिए।


7

मुझे नहीं लगता कि केवल स्थिरांक के लिए इंटरफेस होना एक अच्छी बात है ।

लेकिन अगर एक इंटरफ़ेस जो व्यवहार को परिभाषित करता है (कक्षाएं लागू करने वाले तरीकों को लागू करना चाहिए), में स्थिरांक हैं, तो यह ठीक है। यदि यह एपीआई में "कुछ कार्यान्वयनकर्ता के विवरण को लीक करता है, तो यह इस तरह से होना चाहिए कि यह होना चाहिए। वे यह भी लीक कर रहे हैं कि कार्यान्वयनकर्ता फू और बार विधियों को लागू करता है।

उदाहरण के लिए java.awt.Transparency इंटरफ़ेस लें। इसमें OPAQUE, BITMASK और TRANSLUCENT कॉन्स्टेंट हैं, लेकिन इसमें ट्रान्सपैरेंसी () विधि भी है।

यदि डिजाइनर ने उन स्थिरांक को वहां रखा है, तो यह वह है क्योंकि उसने सोचा कि यह इंटरफ़ेस का हिस्सा होने के लिए पर्याप्त स्थिर होगा, जैसा कि getTransparency () है।


2

सोचें कि यह एक दृष्टिकोण है जो ज्यादातर जगहों पर लोकप्रिय है जहां अनुबंध द्वारा डिजाइन प्रचलित है।
अंतर अनुबंध हैं। इंटरफेस में स्थिरांक रखने का मतलब है कि अनुबंध द्वारा पालन करने वाला हर वर्ग निरंतर द्वारा पहचाने गए मूल्य / अवधारणा से सहमत है।


1
इंटरफेस सार्वजनिक अनुबंध हैं। लगातार घाटी निजी चिंताएं हैं, सार्वजनिक इंटरफ़ेस को अपने नामों को उजागर करना चाहिए। यह एक अमूर्त वर्ग के लिए सबसे अच्छा बचा है।
8

मामले में मामले: javax.naming.Context, javax.ims.Session, और ऐसे सैकड़ों इंटरफेस ...
CMR

2
@jwenting इसके अलावा, "at most expose their names"मूल्यों को उजागर किए बिना, एक सार्वजनिक इंटरफ़ेस कर सकता है ?
सीएमआर

मुझे लगता है कि प्रोग्रामिंग भाषा पर निर्भर करेगा। जावा के मामले में, नहीं।
jwenting 15

2

एक कंपनी जिसका मैंने इंटरफ़ेस-आयातित 1 स्थिरांक का भारी उपयोग किया था । मुझे नहीं लगता कि इससे कोई नुकसान हुआ है।

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

इंटरफेस के बारे में अच्छी बात यह है कि यह आपको किसी भी तरह से काम करने का लाभ देता है - आपके द्वारा आवश्यक सभी नामस्थानों में लाएं, या उनमें से कोई भी नहीं (और उन्हें स्पष्ट रूप से एक्सेस करें, साथ MyInterface.CONSTANT)। बहुत अधिक के रूप में एक ही बात है import static MyInterface.*, लेकिन थोड़ा और अधिक स्पष्ट है।


1: यदि आप जावा से परिचित नहीं हैं, तो मेरा मतलब importकीवर्ड नहीं है , मेरा मतलब है कि मैं इसमें लाया गया हूंimplements MyConstantsInterface


1

मैं एक ऐसी पृष्ठभूमि से आता हूं जो मुख्य रूप से 'एडा रास्ता' और '.नेट तरीका' से प्रभावित है। मैं नहीं कहूंगा, कि इंटरफेस के भीतर स्थिरांक घोषित करना सबसे अच्छा नहीं है। इसे c # में तकनीकी रूप से अनुमति नहीं है।

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

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

अधिक तकनीकी गाइड के लिए: download.oracle.com/javase/1.5.0/docs/guide/language/static-import.html


स्टैटिक इम्पोर्ट (१.५) का जिक्र करते हुए अधिक लिंक जोड़ना: १. विकिपीडिया 2. ओरेकल डॉक्स का जिक्र @Justinc
Abhijeet

1
So when should you use static import? Very sparingly! Only use it when you'd otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes. If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. ओरेकल डॉक्स
अभिजीत

1

नहीं, यह एक सामान्य बुरा अभ्यास नहीं है।

मुद्दा यह है कि किसी भी अन्य कलाकृतियों के रूप में स्थिरांक को न्यूनतम दृश्यता और उचित अमूर्त स्तर के नियमों के तहत पेश किया जाना चाहिए।

सिंटैक्स का उपयोग केवल इसलिए कि आप कर सकते हैं असली समस्या है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.