जावा में मार्कर इंटरफेस का उपयोग क्या है?

48

जावा के पिछले संस्करणों में, Marker Interfaces कक्षा के बारे में मेटाडेटा घोषित करने का एकमात्र तरीका था। उदाहरण के लिए, सीरियलज़ेबल मार्कर इंटरफेस एक वर्ग के लेखक को कहता है कि धारावाहिक और deserialized जब उनकी कक्षा सही ढंग से व्यवहार करेंगे।

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

स्रोत

2010-01-03 15:05:18

+16

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

+9

@Chris तो क्या आप सही हैं या जोश ब्लोच यहां हैं? http://stackoverflow.com/a/5080547/632951 – Pacerier

+1

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

4

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

public void registerObject(Serializable obj);

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

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

एक सुरक्षा पहलू भी है। आप सबकुछ क्रमबद्ध नहीं करना चाहते हैं - अन्यथा आप गलती से पासवर्ड (या) serialization के माध्यम से अन्य संवेदनशील डेटा का पर्दाफाश कर सकते हैं।

स्रोत

2010-01-03 15:01:43

6

इस तरह के मार्कर इंटरफेस इस मामले में उपयोगी होते हैं कि कोई ऑब्जेक्ट कुछ मार्कर इंटरफ़ेस को लागू करता है या नहीं।

Serializable के मामले में, प्रतिबिंब वस्तुओं के क्षेत्रों को क्रमबद्ध करने के लिए उपयोग किया जाएगा।

अब एनोटेशन को प्राथमिकता दी जाती है क्योंकि वे उप-वर्गों के प्रचार नहीं करते हैं।

Marker interface pattern देखें।

स्रोत

2010-01-03 15:02:17

+2

Serializable, नहीं ISerializable :) – Bozho

+1

हाँ मैं इसे में गड़बड़, मैं हमेशा के साथ अपने इंटरफेस नाम लगाकर कर रहा हूँ "मैं" :) –

+3

@ ग्रेगरी हेरेसी, यह जावा है! और यहां तक कि .NET दुनिया में, यह COM (बुरा) सम्मेलन भुला दिया जाना चाहिए! –

2

उन्हें मार्कर इंटरफेस कहा जाता है। और जैसा कि नाम का तात्पर्य है, वे मार्क कि कुछ वस्तु कुछ प्रकार के संचालन के लिए उपलब्ध है।

Serializable का अर्थ है कि वस्तु जावा क्रमबद्धता के लिए योग्य है, उदाहरण के लिए।

इस पर चर्चा की गई है कि उन्हें एनोटेशन द्वारा प्रतिस्थापित नहीं किया जाना चाहिए, क्योंकि उनके कार्य काफी समान हैं।

स्रोत

2010-01-03 15:02:17 Bozho

2

यदि आप एक इंटरफ़ेस लागू करते हैं तो instanceof सत्य होगा। यदि आपके पास इंटरफ़ेस को लागू करने के लिए कुछ भी नहीं है तो आप मेटा-डेटा के साथ क्लास को चिह्नित करने के लिए इसका उपयोग कर सकते हैं जैसे एनोटेशन जावा 1.5 के लिए करते हैं और बिना किसी विशेष काम करने के लिए कार्यान्वयन को मजबूर किए बिना।

स्रोत

2010-01-03 15:06:03 cyborg

1

आप तर्क में सही हैं कि एक खाली इंटरफ़ेस प्रोग्राम के "मानक" निष्पादन को प्रभावित नहीं करता है जो फ़ील्ड के निरीक्षण/उत्परिवर्तन और विधियों को प्रेषित करने पर आधारित है।

हालांकि, प्रतिबिंब के साथ संयोजन में उपयोग किए जाने पर मार्कर इंटरफ़ेस उपयोगी होता है: एक लाइब्रेरी/विधि निरीक्षण (प्रतिबिंब के माध्यम से) एक ऑब्जेक्ट और अलग-अलग काम करता है यदि इसकी कक्षा मार्कर इंटरफ़ेस को लागू करती है। जावा 5 के अनुसार मार्कर इंटरफेस के लिए बहुत कम आवश्यकता है - जावा एनोटेशन के माध्यम से वही "मार्किंग" सुविधा हासिल की जा सकती है - जो (फिर से) उनके अधिकांश प्रभाव प्रतिबिंब-आधारित कोड के माध्यम से हासिल किया जाएगा।

स्रोत

2010-01-03 15:07:06

75

यहोशू बलोच: प्रभावी जावा 2 संस्करण, पी 179

मद 37: का प्रयोग करें मार्कर इंटरफेस को परिभाषित करने के प्रकार

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

निजी तौर पर मुझे लगता है कि नहीं कर सकता कि मैं जोशुआ की प्रणाम करता हूँ पर त्रुटियों को पकड़ने के लिए अनुमति देता है इस विषय पर बेहतर ज्ञान।

स्रोत

2011-02-22 16:00:31

+2

यूप ... बहुत अच्छा :) – agpt

+0

समस्या यह है कि यह अक्सर विपरीत है आइटम 1: प्रकारों को परिभाषित करने के लिए इंटरफ़ेस का उपयोग करें। "Serializable" एक प्रकार नहीं है, यह एक संपत्ति/व्यवहार है। –

+3

असल में, यहां तक कि "Serializable" भी एक प्रकार के रूप में देखा जा सकता है। निम्न विधि हस्ताक्षर पर विचार करें: सार्वजनिक शून्य क्रमबद्ध (Serializable ऑब्जेक्ट ToSerialize); इस मामले में, यह संकलन समय पर स्पष्ट है कि केवल धारावाहिक वस्तुओं को "धारावाहिक" में पारित किया जा सकता है, यह एनोटेशन के साथ संभव नहीं है। –

-1

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

स्रोत

2012-06-27 15:53:02 Chanikag

+1

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

-1

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

और अधिक पढ़ें: http://javarevisited.blogspot.com/2012/01/what-is-marker-interfaces-in-java-and.html#ixzz2v6fIh1rw

स्रोत

2014-03-05 16:30:32 user3293519

+1

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

जावा में मार्कर इंटरफेस का उपयोग क्या है?

उत्तर

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