आप जावा के @ ऑवरराइड एनोटेशन का उपयोग कब और क्यों करते हैं?

498

जावा के @Overrideएनोटेशन का उपयोग करने के लिए सर्वोत्तम अभ्यास क्या हैं और क्यों?

ऐसा लगता है जैसे @Overrideएनोटेशन के साथ हर एक ओवरराइड विधि को चिह्नित करना ओवरकिल होगा । क्या कुछ निश्चित प्रोग्रामिंग स्थितियां हैं जो @Overrideऔर अन्य लोगों को उपयोग करने के लिए कहते हैं जिन्हें कभी भी उपयोग नहीं करना चाहिए @Override?

java annotations

— एलेक्स बी
स्रोत

515

हर बार जब आप दो लाभों के लिए एक विधि को ओवरराइड करते हैं तो इसका उपयोग करें। ऐसा करें कि आप कंपाइलर चेकिंग का लाभ उठा सकें यह सुनिश्चित करने के लिए कि आप वास्तव में एक विधि को ओवरराइड कर रहे हैं जब आपको लगता है कि आप हैं। इस तरह, यदि आप किसी विधि के नाम को गलत तरीके से याद करने की सामान्य गलती करते हैं या मापदंडों का सही ढंग से मिलान नहीं करते हैं, तो आपको चेतावनी दी जाएगी कि आप विधि वास्तव में ओवरराइड नहीं करते हैं जैसा कि आप सोचते हैं कि यह करता है। दूसरे, यह आपके कोड को समझने में आसान बनाता है क्योंकि यह अधिक स्पष्ट है जब तरीकों को ओवरराइट किया जाता है।

इसके अतिरिक्त, जावा 1.6 में आप इसका उपयोग तब चिह्नित कर सकते हैं जब कोई विधि समान लाभों के लिए इंटरफ़ेस लागू करती है। मुझे लगता है कि एक अलग एनोटेशन (जैसे @Implements) होना बेहतर होगा , लेकिन यह कुछ भी नहीं से बेहतर है।

— डेव एल।
स्रोत

4

"समझने में आसान" जैसी समान पंक्तियों के साथ, IDEs @Override एनोटेशन और नेत्रहीन रूप से संपादक में ओवरराइडिंग विधि को चिह्नित करेगा।

— बॉब क्रॉस

47

कुछ IDE एक ओवरराइड विधि को चिह्नित करेंगे जो @Override एनोटेशन को भी याद कर रही है।

— जय आर।

20

अन्य लाभ यह है कि यदि माता-पिता वर्ग बदलते हैं, तो संकलक यह सुनिश्चित करेगा कि बच्चे की कक्षाओं को भी अपडेट किया गया है।

— डेविड

4

@ जय आर .: सच। तथ्य की बात के रूप में, जैसे कि यह गायब है, तो एक्लिप्स भी स्वचालित रूप से @ ऑवरराइड जोड़ सकता है।

— साल्सेक

32

यदि किसी अन्य व्यक्ति को यहां स्पष्ट रूप से अनिर्दिष्ट परिवर्तन के कारण 1.5 से 1.6 तक @Overrides के लिए इंटरफेस से आने वाले तरीकों के कारण मिला है, तो Bugs.sun.com/bugdatabase/view_bug.do?bug_id=50082 पर संबंधित बग प्रतीत होता है। (इसे इंगित करने के लिए धन्यवाद, डेव एल!)

— हेनरिक हेमबर्गर

110

मुझे लगता है कि यह एक संकलन-समय अनुस्मारक के रूप में सबसे उपयोगी है कि विधि का उद्देश्य एक मूल विधि को ओवरराइड करना है। उदहारण के लिए:

protected boolean displaySensitiveInformation() {
  return false;
}

आप अक्सर उपरोक्त विधि की तरह कुछ देखेंगे जो बेस क्लास में एक विधि को ओवरराइड करता है। यह इस वर्ग का एक महत्वपूर्ण कार्यान्वयन विवरण है - हम संवेदनशील जानकारी प्रदर्शित नहीं करना चाहते हैं।

मान लीजिए कि इस पद्धति को मूल वर्ग में बदल दिया गया है

protected boolean displaySensitiveInformation(Context context) {
  return true;
}

यह परिवर्तन किसी भी संकलन समय त्रुटियों या चेतावनियों का कारण नहीं होगा - लेकिन यह उपवर्ग के इच्छित व्यवहार को पूरी तरह से बदल देता है।

अपने प्रश्न का उत्तर देने के लिए: आपको @Override एनोटेशन का उपयोग करना चाहिए यदि सुपरक्लास में समान हस्ताक्षर के साथ विधि की कमी बग का संकेत है।

— जॉन
स्रोत

46

यहाँ कई अच्छे उत्तर हैं, इसलिए मुझे इसे देखने का एक और तरीका प्रदान करें ...

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

इसके बारे में इस तरह से सोचें: जिस समय में आपने यहां पर नेविगेट किया और इस पोस्ट को टाइप किया, आप अपने जीवन के बाकी हिस्सों के लिए @override टाइप करने में जितना खर्च करेंगे, उससे कहीं ज्यादा समय आप इस्तेमाल करते हैं; लेकिन एक त्रुटि जो इसे रोकती है वह आपको घंटों बचा सकती है।

जावा यह सुनिश्चित करने के लिए यह सब कर सकता है कि आपने संपादन / संकलन समय पर कोई गलती नहीं की है, यह पूरी तरह से गलतियों के एक पूरे वर्ग को हल करने का एक मुफ्त तरीका है जो व्यापक परीक्षण के बाहर किसी भी अन्य तरीके से रोकने योग्य नहीं है।

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

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

— बिल के
स्रोत

3

"जब आप कोडिंग कर रहे हैं तो कोई ओवरकिल नहीं है।" मैं इससे सहमत हूं, यही वजह है कि मुझे गतिशील लंग्स इतने गलत लगते हैं (हालांकि मेरे भुगतान किए गए 100% काम अभी रूबी में हैं)।

— डैन रोसेनस्टार्क

4

+1: मेरे पास हो सकता है, हो सकता है, ओवरराइडिंग में गलती के कारण 10 कीड़े - उनमें से किसी एक को खोजने के लिए आवश्यक समय आसानी से मेरे ओवरराइडिंग तरीकों में से हर एक पर @Override टाइप करने का समय पार कर गया हो। इसके अलावा, अगर @ ऑवरराइड कुछ बोझ है, तो आप शायद विरासत का उपयोग कर रहे हैं।

— लॉरेंस डॉल

7

एक बहुत ही नकारात्मक पक्ष यह है कि आप कोड को घोंघे के साथ लिट कर पढ़ने के लिए कठिन बना देते हैं। शायद यह मेरी आईडीई का दोष है, लेकिन मैंने खुद इसका अनुभव किया है।

— अपने मॉड्स का अच्छी तरह से इलाज करें

9

यदि आप "घोंघे" बोझिल पाते हैं, तो आप पर्याप्त टिप्पणियों का उपयोग नहीं कर रहे हैं। वे आपके मेथड हेडर के ठीक ऊपर एक सिंगल लाइन होनी चाहिए जो कि ज्यादातर मामलों में आपकी विधि जितनी बड़ी होनी चाहिए (कुछ लाइनें) सभ्य होवर टेक्स्ट और javadocs प्रदान करने के लिए। मुझे लगता है मैं कह रहा हूं कि समस्या घोंघे नहीं है, यह आपकी पढ़ने की आदत है। क्या कोड में वे सभी कोष्ठक आपको परेशान कर रहे हैं?

— बिल के

4

हां, कोडिंग में ओवरकिल होता है: जब आप टिप्पणी लिखते हैं तो सिर्फ यह बताता है कि कोड स्पष्ट रूप से क्या करता है।

— चींटियों

22

मैं हमेशा टैग का उपयोग करता हूं। यह छोटी गलतियों को पकड़ने के लिए एक सरल संकलन-समय ध्वज है जो मैं कर सकता हूं।

यह tostring()इसके बजाय चीजों को पकड़ लेगाtoString()

छोटी चीजें बड़ी परियोजनाओं में मदद करती हैं।

— jjnguy
स्रोत

18

@Overrideएनोटेशन का उपयोग करना एक सामान्य प्रोग्रामिंग गलती के खिलाफ संकलन-समय सुरक्षा के रूप में कार्य करता है। यदि आप एक विधि पर एनोटेशन रखते हैं, तो यह एक संकलन त्रुटि को फेंक देगा, आप वास्तव में सुपरक्लास पद्धति को ओवरराइड नहीं कर रहे हैं।

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

— toluju
स्रोत

सबसे बढ़िया उत्तर। छोटा एवं सुन्दर। काश, आप यह बता पाते कि "सेफगार्ड" कैसे काम करता है .... किसी ने भी यह नहीं बताया।

— djangofan

यह समझाने के लिए सरल है। यदि आप एक गलती करते हैं (या तो इंटरफ़ेस, अमूर्त वर्ग या उपवर्ग को बदलकर, आपको या तो एक चेतावनी मिलेगी (जैसे कि ग्रहण में) या एक संकलन-समय की त्रुटि आपको बताएगी कि आपका @Override काम नहीं कर रहा है। वास्तविक त्रुटि। संदेश इस बात पर निर्भर करेगा कि क्या बदला गया था, लेकिन एक्लिप्स (उदाहरण के लिए) यह बहुत जल्दी स्पष्ट है कि एक समस्या है: आप उस छोटे से लाल ज़िगज़ैग को रेखांकित करेंगे, और आपत्तिजनक पाठ पर एक हॉवर आपको बताएगा कि क्या गलत है। मैं उस अच्छे मूल्य को बुलाता हूं।

— इचिरो फ्यूरसैटो

14

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

कुछ आईडीई, ग्रहण के रूप में, यहां तक कि जावा 1.6 रनटाइम या उच्चतर के साथ कॉन्फ़िगर किया गया है, वे जावा 1.5 का अनुपालन बनाए रखते हैं और ऊपर वर्णित अनुसार @override का उपयोग करने की अनुमति नहीं देते हैं। उस व्यवहार से बचने के लिए आपको जाना चाहिए: प्रोजेक्ट गुण -> जावा कंपाइलर -> "प्रोजेक्ट विशिष्ट सेटिंग्स सक्षम करें" -> "कंपाइलर कंप्लायंस स्तर" = 6.0, या उच्चतर चुनें।

मैं हर बार इस एनोटेशन का उपयोग करना पसंद करता हूं जब मैं स्वतंत्र रूप से एक विधि को ओवरराइड कर रहा हूं, अगर आधार एक इंटरफ़ेस या वर्ग है।

यह आपको कुछ विशिष्ट त्रुटियों से बचने में मदद करता है, जैसे कि जब आप सोच रहे हों कि आप किसी ईवेंट हैंडलर को ओवरराइड कर रहे हैं और तब आपको कुछ भी नहीं हो रहा है। कल्पना कीजिए कि आप कुछ यूआई घटक के लिए एक इवेंट श्रोता जोड़ना चाहते हैं:

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

उपरोक्त कोड संकलित करता है और चलता है, लेकिन यदि आप माउस को किसी तरह ले जाते हैं तो कुछ "डू कुछ" कोड चला जाएगा, क्योंकि वास्तव में आप आधार विधि को ओवरराइड नहीं कर रहे हैं mouseEntered(MouseEvent ev)। आप बस एक नया पैरामीटर-कम विधि बनाएँ mouseEntered()। उस कोड के बजाय, यदि आपने @Overrideएनोटेशन का उपयोग किया है तो आपने एक संकलन त्रुटि देखी है और आप यह सोचकर समय बर्बाद नहीं कर रहे हैं कि आपका ईवेंट हैंडलर क्यों नहीं चल रहा था।

— डोनल फेलो
स्रोत

8

@ इंटरफ़ेस कार्यान्वयन पर ओवरराइड असंगत है क्योंकि जावा में "इंटरफ़ेस को ओवरराइड करने" जैसी कोई बात नहीं है।

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

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

@ ऑवरराइड का उपयोग करना जब वास्तव में सुपरक्लास में एक विधि को ओवरराइड करना ठीक है।

— रूण
स्रोत

2

उस बिंदु पर अलग-अलग राय हैं। Stackoverflow.com/questions/212614/… देखें ।

— १६

8

ओवरराइड के रूप में इच्छित प्रत्येक विधि और जावा 6+ के लिए इसका उपयोग करने के लिए इसका सबसे अच्छा है, प्रत्येक विधि एक इंटरफ़ेस के कार्यान्वयन के रूप में।

सबसे पहले, यह संकलन-समय पर " hashcode()" के बजाय " " की तरह गलतियाँ पकड़ता है hashCode()। यह डीबग करने के लिए चकित हो सकता है कि आपकी पद्धति का परिणाम आपके कोड से मेल नहीं खाता है क्योंकि वास्तविक कारण यह है कि आपका कोड कभी भी रद्द नहीं किया गया है।

इसके अलावा, अगर एक सुपरक्लास एक विधि हस्ताक्षर को बदलता है, तो पुराने हस्ताक्षर के ओवरराइड को "अनाथ" किया जा सकता है, जो मृत कोड को भ्रमित करने के रूप में पीछे रह जाता है। @Overrideएनोटेशन आप इन अनाथ बच्चों की पहचान ताकि वे नया हस्ताक्षर मिलान करने के लिए संशोधित किया जा सकता मदद मिलेगी।

— एरिक्सन
स्रोत

7

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

इंटरफ़ेस विधियों (1.6+ फ़ीचर) को लागू करते समय @ ऑवरराइड का उपयोग करना मेरे लिए थोड़ा ओवरकिल लगता है। यदि आपके पास कुछ तरीकों का भार है, जिनमें से कुछ ओवरराइड करते हैं और कुछ नहीं करते हैं, तो शायद फिर से खराब डिजाइन (और आपका संपादक शायद दिखाएगा जो कि अगर आपको नहीं पता है)।

— टॉम हॉकिन - डीललाइन
स्रोत

2

दरअसल, यह ओवरराइड इंटरफेस के तरीकों के लिए भी अच्छा है। यदि मैं उदाहरण के लिए एक पुराने, पदावनत विधि को एक अंतरफलक से हटाता हूं, तो उस पद्धति को सभी कार्यान्वयन वर्गों से भी हटा दिया जाना चाहिए - यदि वे @override का उपयोग करते हैं तो उन्हें आसानी से हाजिर कर सकते हैं।

— डोमिनिक सैंडजाजा

7

@ इंटरफेस पर वास्तव में उपयोगी होते हैं, क्योंकि इंटरफ़ेस बदलने पर आपको चेतावनी मिलेगी।

— असगीर एस निल्सन
स्रोत

7

एक और बात यह है कि यह कोड को पढ़ते समय यह अधिक स्पष्ट करता है कि यह मूल वर्ग के व्यवहार को बदल रहा है। थान डिबगिंग में मदद कर सकता है।

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

— Diastrophism
स्रोत

हां, वास्तव में - आइटम 36 :)

— क्रिस किम्पटन

6

यह इंटरफ़ेस विधि लागू करते समय @ ऑवरराइड का उपयोग करने के लिए बिल्कुल कोई मतलब नहीं है। उस स्थिति में इसका उपयोग करने का कोई फायदा नहीं है - संकलक पहले से ही आपकी गलती को पकड़ लेगा, इसलिए यह सिर्फ अनावश्यक अव्यवस्था है।

— स्टीव आर।
स्रोत

6

@Overrideइंटरफ़ेस का उपयोग करने पर आपको यह देखने के लिए बाध्य किया जाएगा कि इंटरफ़ेस में कोई विधि निकाल दी गई है।

— एलेक्स बी

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

— लॉरेंस डॉल

6

जब भी कोई विधि किसी अन्य विधि को ओवरराइड करती है, या कोई विधि किसी इंटरफ़ेस में हस्ताक्षर को लागू करती है।

@Overrideएनोटेशन आप भरोसा दिलाते हैं कि आप इस तथ्य ओवरराइड कुछ में किया था। एनोटेशन के बिना आप एक गलत वर्तनी या पैरामीटर प्रकार और संख्या में अंतर का जोखिम उठाते हैं।

— ग्रेग मैट्स
स्रोत

1

आप इसका उपयोग केवल जावा 1.6

— डेव एल।

5

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

— हांक गे
स्रोत

5

सबसे अच्छा अभ्यास हमेशा इसका उपयोग करना है (या आपके लिए आईडीई उन्हें भरना है)

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

उस तरह का सुरक्षा जाल हमेशा अच्छा होता है।

1

इसलिए, यदि आप मूल पद्धति को बदलते हैं, और आपका उपयोग चाइल्ड क्लास की विधि में @ ऑवरराइड का उपयोग नहीं करता है, तो संकलन कुछ भी कहेगा या चुप रहेगा? क्या "ओवरराइड" का उपयोग आपको अधिक जानकारी देगा, और यदि हां, तो क्या?

— djangofan

5

मैं हर जगह इसका इस्तेमाल करता हूं। अंकन के तरीकों के लिए प्रयास के विषय पर, मैंने एक्लिप्स को मेरे लिए ऐसा करने दिया, यह कोई अतिरिक्त प्रयास नहीं है।

मैं लगातार रीफैक्टरिंग के बारे में धार्मिक हूं .... इसलिए, मैं हर छोटी चीज का उपयोग करूंगा ताकि इसे और अधिक आसानी से किया जा सके।

— willCode4Beer
स्रोत

5

केवल विधि घोषणाओं पर उपयोग किया जाता है।
इंगित करता है कि एनोटेट विधि घोषणा सुपरस्क्रिप्ट में एक घोषणा को ओवरराइड करती है।

यदि लगातार उपयोग किया जाता है, तो यह आपको एक बड़े वर्ग के नापाक कीड़े से बचाता है।

इन बग्स से बचने के लिए @ ऑवरराइड एनोटेशन का उपयोग करें: (निम्नलिखित कोड में बग को स्पॉट करें :)

public class Bigram {
    private final char first;
    private final char second;
    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }
    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }
    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<Bigram>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

स्रोत: प्रभावी जावा

— जय
स्रोत

मुझे नहीं पता कि जावा में ऑपरेटर पूर्वता नियम क्या हैं, लेकिन आपका समान तरीका BUUUUUUUUUUUG चिल्ला रहा है! मैं लिखता हूँ (b.first == first) && (b.second == second), भले ही &&पहले की तुलना में कम था ==।

— पियून

क्या आप जानते हैं कि आपका लिंक उस पृष्ठ के उपयोगी हिस्से को कवर करते हुए 'आपको सदस्यता अवश्य देनी चाहिए' संदेश दिखाता है?

— एड्रियानो वरोली पियाजा

@ एड्रियानो: सॉरी यार !! हूँ लाचार !! जब मैंने I उत्तर ’लिखा, तो यह उपलब्ध था। कोई चिंता नहीं..बस किताब। यह इसके लायक है !!

— जय

5

समान पद्धति ओवरराइड नहीं करती है: मूल Object::equalsहै boolean equals(Object), जबकि ओवरराइड equalsहै boolean equals(Bigram), जिसमें एक अलग विधि हस्ताक्षर है, जो ओवरराइड नहीं करता है। @ ऑवरराइड को जोड़ने से equalsइस ब्लंडर का पता चलेगा।

— मिंग-तांग

3

ओवरराइड का उपयोग करते समय सावधान रहें, क्योंकि आप बाद में स्टारयूएमएल में रिवर्स इंजीनियर नहीं कर सकते हैं; पहले ओम्ल बनाओ।

— होरातिउ जेफली
स्रोत

2

ऐसा लगता है कि यहाँ ज्ञान बदल रहा है। आज मैंने IntelliJ IDEA 9 स्थापित किया और देखा कि इसका " लापता @Override निरीक्षण " अब न केवल अमूर्त विधियों को लागू करता है, बल्कि इंटरफ़ेस विधियों को भी लागू करता है। मेरे नियोक्ता के कोड आधार और अपने स्वयं के प्रोजेक्ट में, मुझे लंबे समय से केवल पूर्व लागू अमूर्त विधियों के लिए @ ऑवरराइड का उपयोग करने की आदत है। हालांकि, इस आदत पर पुनर्विचार करते हुए, दोनों मामलों में एनोटेशन का उपयोग करने का गुण स्पष्ट हो जाता है। अधिक क्रिया होने के बावजूद, यह नाजुक आधार वर्ग समस्या (सी ++ के रूप में गंभीर नहीं है - संबंधित उदाहरण) के खिलाफ की रक्षा करता है जहां इंटरफ़ेस विधि का नाम बदलता है, एक व्युत्पन्न वर्ग में होगा-लागू करने की विधि को अनाथ करना।

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

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

— seh
स्रोत

2

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

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

इसलिए जब हम बहुरूपता का उपयोग करने के लिए उस पद्धति को ओवरराइड करना चाहते हैं, तो हमें विधि के ऊपर @Override जोड़ना बेहतर होगा।

— lzlstyle
स्रोत

1

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

— बर्लिन ब्राउन
स्रोत

0

यह आपको (अच्छी तरह से संकलक) को पकड़ने की अनुमति देता है जब आपने गलत तरीके से वर्तनी का उपयोग किया है जिसे आप ओवरराइड कर रहे हैं।

— JeeBee
स्रोत

0

ओवरराइड एनोटेशन का उपयोग कंपाइलर का लाभ उठाने के लिए किया जाता है, यह जाँचने के लिए कि क्या आप वास्तव में पैरेंट क्लास से कोई तरीका अपना रहे हैं। इसका उपयोग यह सूचित करने के लिए किया जाता है कि क्या आप कोई गलती करते हैं जैसे किसी विधि का नाम गलत करने की गलती, सही तरीके से मापदंडों का मिलान न करना

— शिव
स्रोत

0

मुझे लगता है कि जब भी अनुमति दी जाए @override को कोड करना सबसे अच्छा है। यह कोडिंग के लिए मदद करता है। हालाँकि, ध्यान दिया जाना चाहिए, इलिस हेलीओस के लिए, या तो sdk 5 या 6, लागू इंटरफ़ेस विधियों के लिए @override एनोटेशन की अनुमति है। गैलीलियो के लिए, या तो 5 या 6, @override एनोटेशन की अनुमति नहीं है।

— lwpro2
स्रोत

0

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

— gprathour
स्रोत

0

मेरे लिए @ ऑवरराइड सुनिश्चित करता है कि मेरे पास विधि के हस्ताक्षर सही हैं। अगर मैंने एनोटेशन में डाला है और विधि सही ढंग से वर्तनी नहीं है, तो संकलक शिकायत करता है कि मुझे कुछ गलत है।

— घाटी
स्रोत

0

सरल-जब आप अपने सुपरक्लास में मौजूद एक विधि को ओवरराइड करना चाहते हैं, @Overrideतो सही ओवरराइड बनाने के लिए एनोटेशन का उपयोग करें । यदि आप इसे सही ढंग से ओवरराइड नहीं करते हैं तो संकलक आपको चेतावनी देगा।

— श्री
स्रोत