अब जब जावा इंटरफ़ेस में सभी विधि घोषणाएं सार्वजनिक सार नहीं हैं, तो क्या इन संशोधकों के साथ तरीकों को घोषित किया जाना चाहिए?

Question

जावा 8 के साथ शुरू, defaultविधियों को इंटरफेस में पेश किया गया था। प्रभावी रूप से, इसका मतलब है कि सभी तरीके एक में नहीं interfaceहैं abstract।

जावा 9 (शायद) के साथ शुरू, privateविधियों की अनुमति होगी। इसका मतलब है कि सभी तरीके एक नहीं interfaceहैं public abstract।

सवाल "क्या जावा इंटरफ़ेस में तरीकों को publicएक्सेस संशोधक के साथ या बिना घोषित किया जाना चाहिए ?" स्टैक ओवरफ्लो में /programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m पर पूछा गया था

वहाँ, अधिकांश उत्तरों ने तर्क दिया कि public abstractइसका उपयोग नहीं किया जाना चाहिए क्योंकि कैन में कोई भी विधि interfaceइसके अलावा और कुछ नहीं हो सकती है public abstract। अब यह मामला नहीं है।

तो, इंटरफेस की इन नई विशेषताओं के प्रकाश में, क्या public abstractजावा इंटरफेस विधि घोषणा में कीवर्ड का उपयोग किया जाना चाहिए ?

मेरे विशिष्ट वातावरण में, हमारे पास ऐसे लोग होंगे जो अनुभवी सॉफ्टवेयर इंजीनियर हैं, लेकिन जावा में अनुभवी नहीं हैं, समय-समय पर जावा कोड पढ़ते हैं। मुझे लगता है कि public abstractकीवर्ड छोड़ने से अब उन लोगों के लिए भ्रम का एक अतिरिक्त बिंदु बन जाएगा, जो इन कीवर्ड के उपयोग के लिए अलग-अलग नियम होने के इतिहास से परिचित नहीं हैं।

Comments

आपने जावा 8 जेएलएस की जांच की? SO पर पुराने स्वीकृत उत्तर के समान खंड बताता है कि डिफ़ॉल्ट तरीकों की शुरूआत से पहले की सिफारिश नहीं बदली गई थी, जो एक ही अतिरेक के विचार पर आधारित थी: "एक इंटरफ़ेस विधि जिसमें एक defaultसंशोधक या एक staticसंशोधक की कमी होती है abstract... यह अनुमति है, लेकिन शैली के रूप में हतोत्साहित करने के abstractलिए, इस तरह की विधि घोषणा के लिए संशोधक को स्पष्ट रूप से निर्दिष्ट करें । " आप क्यों उम्मीद करते हैं कि चीजें बदलनी चाहिए?

— gnat

मैंने सोचा कि चीजें बदल सकती हैं क्योंकि एक विधि के लिए निहित abstractहोने की स्थिति तेजी से जटिल होती जा रही है। जावा 9 में, कि एक ही वाक्य हो सकता है, "एक इंटरफेस विधि एक कमी defaultसंशोधक या एक staticसंशोधक या एक privateआपरिवर्तक परोक्ष सार है ..." इसके अतिरिक्त, स्पष्ट रूप से कीवर्ड इस्तेमाल नहीं करने के लिए सहायक तर्क, अर्थात्, सभी इंटरफ़ेस तरीके हैं कि public abstract, अब मूट हैं।

— डेविड कैंपबेल

टीबीएच मैं "डिफ़ॉल्ट" विधियों के पीछे के तर्क को नहीं समझता हूं, और यहां तक ​​कि स्थिर तरीके भी उस दायरे के बाहर तक पहुंचते हैं जो इंटरफेस आमतौर पर करने का इरादा रखते हैं। अंतरात्मा की आवाज से दुःख का अनुभव नहीं किया जाना चाहिए। इसलिए वे संदर्भ के लिए उपयोगी प्रकार हैं।

— ट्रिक्स वुल्फ

@ ट्रिक्सवॉल्फ डिफ़ॉल्ट तरीके इंटरफेस को विकसित करने की अनुमति देते हैं। पहले, और कक्षाओं के विपरीत, एक विधि जोड़ने से हर कार्यान्वयन टूट जाएगा; अब, आप एक इंटरफ़ेस विकसित कर सकते हैं जब तक कि आपके पास एक अच्छा उम्मीदवार डिफ़ॉल्ट है। के अलावा विचार करें streamकरने के लिए java.util.Collection, या Map.getOrDefault()। वैकल्पिक एक नया उप-इंटरफ़ेस बनाना है, और सभी को नीचे की ओर लाना है, जैसे कि ग्राफिक्स 2 डी, और किसी को भी मज़ा नहीं आया!

— सुसानडब्ल्यू

Answer 1

StackOverflow जवाब पर विस्तार करने के लिए:

1. publicपहुँच संशोधक क्योंकि की जरूरत नहीं है

   एक इंटरफेस के शरीर में हर विधि घोषणा स्पष्ट रूप से सार्वजनिक है ()6.6)। इसे अनुमति दी गई है, लेकिन एक शैली में एक विधि घोषणा के लिए सार्वजनिक रूप से निर्दिष्ट करने के लिए सार्वजनिक रूप से निर्दिष्ट करने के लिए, शैली के रूप में हतोत्साहित किया जाता है। ( धारा 9.4 )

2. abstractपहुँच संशोधक क्योंकि की जरूरत नहीं है

   एक डिफ़ॉल्ट विधि एक विधि है जो डिफ़ॉल्ट संशोधक के साथ एक इंटरफ़ेस में घोषित की जाती है ; इसका शरीर हमेशा एक ब्लॉक द्वारा दर्शाया जाता है ।

   तथा...

   एक डिफ़ॉल्ट संशोधक या एक स्थैतिक संशोधक की कमी वाला इंटरफ़ेस विधि संक्षेप में सार है , इसलिए इसका शरीर एक अर्धविराम द्वारा दर्शाया जाता है , न कि एक ब्लॉक।

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

---

एक उत्तर पर टिप्पणी में से एक ने कहा:

उन्हें मत सोचो! मैंने हमेशा सार्वजनिक अमूर्त को जोड़ा, शैली पुलिस के बावजूद, इसने चीजों को स्पष्ट किया और पाठक को याद दिलाया। अब मैं आश्वस्त हूं क्योंकि जावा 8 और 9 जटिल चीजें हैं (user949300)

StackOverflow प्रश्न पर एक टिप्पणी (18 बार मतदान हुआ) इस का खंडन करता है:

यह बुरा है क्योंकि इसे सार्वजनिक रूप से लिखने का अर्थ है कि यह गैर-सार्वजनिक (पेसियर) हो सकता है

कोड के निहितार्थ, विशेष रूप से इंटरफेस, महत्वपूर्ण हैं।

Comments

StackOverflow से आपके द्वारा उद्धृत टिप्पणी अब पुरानी हो गई है। यह कहना कि सार्वजनिक संशोधन को जोड़ना खराब है क्योंकि इसका अर्थ है कि यह गैर-सार्वजनिक है विरोधाभासी हो सकता है। विधि गैर-सार्वजनिक हो सकती है।

— डेविड कैम्पबेल

@DavidCampbell: खैर, मुझे लगता है कि जावा 9 के आने के बाद यह सवाल बेहतर हो सकता है। :) के रूप में अभी तक होने वाली जावा कल्पना इस सवाल का जवाब हो सकता है।

— ग्रेग बरगार्ड

Answer 2

क्या एक ब्लॉक स्टेटमेंट निहितार्थ की कमी पर्याप्त नहीं है? क्या आप extends Objectयह घोषित करेंगे कि यह निहित है?

यदि डेवलपर अतिरेक को नहीं समझता है, तो संभावना है कि वे भाषा सुविधा के पीछे की अवधारणा को पूरी तरह से नहीं समझ सकते हैं , जो कि संशोधक के बारे में भ्रमित होने की तुलना में एक बड़ी समस्या है।

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

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

Comments

उन्हें मत सोचो! मैंने हमेशा public abstractशैली पुलिस के बावजूद पहले जोड़ा , क्योंकि इससे चीजें स्पष्ट हुईं और पाठक को याद दिलाया। अब मैं वंदित हूं क्योंकि जावा 8 और 9 चीजें जटिल हैं :-)। जावा पहले से ही बहुत बेमानी है।

— user949300

@ user949300 क्या आप extends Objectहर उस वर्ग को भी जोड़ सकते हैं जो सीधे तौर पर प्राप्त होता है Object? यह जानकारी है कि एक डेवलपर को पहले से ही इसके बारे में पता होना चाहिए, यही वजह है कि यह अनुमान है। स्क्रीन पर कम बेकार जानकारी, महत्वपूर्ण जानकारी को संसाधित करना आसान है। उम्मीद है कि मैंने आपको अंधेरे पक्ष में आने के लिए मना लिया है (इसे प्राप्त करें? क्योंकि निहित सामान नहीं देखा जा सकता है)। यदि नहीं, यह एक शॉट haha ​​के लायक था। अंत में, यह क्या डेवलपर के लिए कोड को प्रबंधित करने के लिए आसान बनाता है के लिए नीचे आता है

— विंस Emigh

@ user949300 ऐसा करने से आप इंटरफ़ेस के तरीकों में इन घोषणाओं को शामिल नहीं करने के बारे में भ्रम पैदा करने की अधिक संभावना है। यदि आपके कोड को देखकर जावा सीखने वाले कोई भी डेवलपर हैं, तो आपने संभावित रूप से इंटरफ़ेस घोषणाओं के सिंटैक्स के बारे में उनकी समझ को बढ़ावा दिया है।

— जिमीजैम

विंस, नहीं, मैं ऑब्जेक्ट का विस्तार नहीं करूंगा, हालांकि जब मैं ऐसा कोड देखता हूं तो मैं फिट नहीं बैठता हूं। @JimmyJames, अगर कोई लगातार ऐसा करने के लिए सार्वजनिक सार जोड़ रहा है, तो मुझे कोई भ्रम नहीं दिखता। क्या मैं कुछ भूल रहा हूँ? OTOH, मैं अव्यवस्था पर अपनी बात देख रहा हूँ। उदाहरण के लिए, मैं finalविधि के तर्कों से पहले नहीं जोड़ता जब तक कि कुछ मज़ेदार की आवश्यकता न हो (जैसे एक अनाम आंतरिक वर्ग आदि ...)

— user949300

@ user949300 इसका मतलब है कि अगर कोई उपयोगकर्ता पहले से ही संशोधक की कमी और इसके पीछे के कारण से अवगत था, तो वे सवाल कर सकते हैं कि जब वे देखते हैं तो संशोधक वहां क्यों होते हैं, तो उन्हें लगता है कि इसके पीछे एक वास्तविक कारण हो सकता है सिर्फ स्पष्ट होने के अलावा। । अगर मैंने देखा तो मैं फिट नहीं होता extends Object, लेकिन यह निश्चित रूप से एक झंडा उठाएगा और मुझसे सवाल करेगा कि क्यों। जैसा कि मैंने पोस्ट में उल्लेख किया है, ऐसी चीजें करने का मतलब यह हो सकता है कि डेवलपर को इस बात की गलतफहमी हो सकती है कि कुछ कैसे काम करता है (यह नहीं जान सकता है कि सभी ऑब्जेक्ट पहले से ही विस्तारित हैं Object, इसलिए स्पष्ट विस्तार)

— विंस एमघे