@interface एनोटेशन को परिभाषित करने के लिए क्यों उपयोग किया जाता है?

Question

मैं जावा में कुछ समय या अंत उपयोगकर्ता के रूप में एनोटेशन का उपयोग कर रहा हूं लेकिन हाल ही में मैंने अपने स्वयं के एनोटेशन प्रकार बनाने का फैसला किया है और मुझे जावा में एनोटेशंस के साथ एनोटफेस को परिभाषित करने के लिए सिंटैक्स मिल गया है, जो बहुत अजीब है। मेरा सवाल यह है कि जावा ने एंटर के लिए किए गए एक नए कीवर्ड को शुरू करने के बजाय एनोटफेस को परिभाषित करने के लिए @interface का उपयोग क्यों किया? क्या @interface वाक्यविन्यास का कुछ फायदा है जो मुझे याद आ रही है?

मैं डिजाइन विचारों को समझने के लिए कह रहा हूं कि एनोटेशन के डिजाइनरों के माध्यम से मुझे यकीन है कि उन्होंने एनोटेशन को परिभाषित करने के लिए एक नया कीवर्ड शुरू करने के विचार से खिलवाड़ किया होगा।

@interface में उदाहरण के लिए बहुत सारे प्रतिबंध हैं, आप विस्तार का उपयोग नहीं कर सकते हैं, ऐसे विशिष्ट प्रकार हैं जिनका उपयोग आप एनोटेशन सदस्य जैसे दिनांक को परिभाषित करते समय नहीं कर सकते। मुझे @interface में क्या स्पष्ट हो सकता है, इस पर प्रतिबंध मिलते हैं और यह मुझे हैक की तरह लगता है।

Answer 1

स्पष्ट रूप से डिजाइनर कोई कीवर्ड नहीं जोड़ना चाहते थे। ऐसा कुछ नहीं जो आप हल्के ढंग से करते हैं, क्योंकि यह मौजूदा सही कार्यक्रमों को अमान्य करता है। कोबोल-9एक्स समिति ने दर्जनों शब्दों को जोड़ा, यदि सैकड़ों कीवर्ड नहीं हैं और आपको चीखें सुननी चाहिए थीं। कुछ कंपनियां मानकों के शरीर पर मुकदमा करने के बारे में बात कर रही थीं।

Answer 2

मैं इस विशेष मामले के लिए सटीक कारणों को पता नहीं है, लेकिन सामान्य रूप में:

सभी मौजूदा स्रोत कोड है कि एक पहचानकर्ता के रूप में है कि विशेष कीवर्ड के उपयोग करने के लिए होता है की एक भाषा टूटता संगतता में एक नया कीवर्ड का परिचय।

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

enum के मामले में, जिसका आपने उल्लेख किया है, मुझे लगता है कि उन्होंने अनुमान लगाया है कि यह (ए) अन्य सी-शैली भाषाओं में एक आम कीवर्ड है, (बी) आमतौर पर केवल मौजूदा कोड में स्थानीय-स्कोप पहचानकर्ता के रूप में उपयोग किया जाता है और इस प्रकार आसानी से refactored और (सी) किसी भी विकल्प विकल्प के बिना। उन्होंने फैसला किया कि लाभ लागत से अधिक है। एनोटेशन मामले के लिए, उन्होंने जाहिर तौर पर अन्यथा निर्णय लिया।

एक तरफ के रूप में, आपको Josh Bloch's Effective API Design talk देखने में रुचि हो सकती है जो इन कई विचारों पर छूता है।

Answer 3

एनोटेशन घोषणाएं आमतौर पर देखने के लिए बहुत घृणित होती हैं।

उन्होंने शायद सोचा कि केवल कुछ (विशेषज्ञ) घोषणाएं करेंगे और एनोटेशन की प्रक्रिया करेंगे, अधिकतर प्रोग्रामर विशेषज्ञों द्वारा डिज़ाइन की गई टिप्पणियों का उपयोग करेंगे। इसलिए उन्होंने एनोटेशन घोषणाओं को सुशोभित करने के लिए बहुत कुछ नहीं सोचा था। enum का उपयोग अधिकांश प्रोग्रामर द्वारा अपने दैनिक काम में किया जाना चाहिए, इसलिए वाक्यविन्यास संक्षिप्त होना चाहिए।

लेकिन अब गुइस/सीडीआई जैसे अधिक से अधिक ढांचे को ऐप प्रोग्रामर को अपनी एनोटेशन घोषित करने की आवश्यकता है। और कई प्रोग्रामर अपनी खुद की टिप्पणियों को डिजाइन और संसाधित करने के लिए पर्याप्त बहादुर महसूस करते हैं। एनोटेशन घोषणाओं के गन्दा वाक्यविन्यास की समस्या अधिक प्रमुख हो जाती है।