इंटरफेसेस में संरक्षित

111

एक interfaceपरिभाषा में सभी तरीके निहित क्यों हैं public? यह एक protectedविधि की अनुमति क्यों नहीं देता है ?

java interface

22

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

— मार्कस ए।

4

@MarkusA। लेकिन इंटरफेस दो-तरफा काम करते हैं, अर्थात वे वर्तमान पैकेज के बाहर की कक्षाओं द्वारा भी लागू किए जा सकते हैं (और फिर शायद इस पैकेज के तरीकों के तर्क के रूप में पारित किए गए हैं)। वर्तमान पैकेज के बाहर का एक वर्ग कुछ सार्वजनिक इंटरफ़ेस के "संरक्षित" तरीकों को कैसे लागू कर पाएगा?

— मार्टिनस्टाइनर

8

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

— सुपरहिट

1

@MarkusA। आपने एक अच्छा बिंदु उठाया, आपको जावा 9 के मॉड्यूल सिस्टम के

— Nir Alfasi

1

यदि इंटरफ़ेस में protectedविधि है, तो सभी कार्यान्वयन वर्ग को इंटरफ़ेस के उप-प्रकार के रूप में देखा जाएगा। और ये सभी वर्ग संरक्षित तरीकों तक पहुंच सकते हैं। क्या यह protectedविधि पर कीवर्ड को बेकार नहीं बनाता है ? जब तक हमारे पास यह प्रतिबंधित करने का कोई तरीका नहीं है कि यह इंटरफ़ेस सुरक्षित कीवर्ड को किस विधि से लागू करता है बेकार है। यदि मैं गलत हूं तो मुझे सही करों!

— अमरनाथ ने

67

क्योंकि एक इंटरफ़ेस का अर्थ है "आप वर्ग के बाहर से क्या देख सकते हैं"। गैर-सार्वजनिक तरीकों को जोड़ने का कोई मतलब नहीं होगा।

— Raveline
स्रोत

16

लेकिन फ़ंक्शन क्यों नहीं हैं जो इंटरफ़ेस के समान पैकेज के केवल सदस्य "वर्ग के बाहर से देख सकते हैं"? मेरे पास कई उपयोग-मामले हैं जहां मैं इसके लिए इच्छा कर रहा था।

— मार्कस ए।

5

@MarkusA। मुझे पता है कि यह देर हो चुकी है, लेकिन फिर आप पूरी तरह से बना सकते हैं abstract class, जो सभी interfaceएस हैं, और जो भी आप चाहते हैं उसे निर्दिष्ट करें। दी गई यह कई कार्यान्वयनों का लाभ देता है जो interfaceजावा में मिलते हैं, लेकिन ईमानदारी से एक अनुबंध स्थापित करना जो कुछ अन्य पैकेजों की सीमाओं का पालन करता है, अप्राप्य और भ्रामक होगा, क्योंकि आप व्यावहारिक रूप से उस पैकेज के बाहर अपने खुद के कार्यान्वयन के तरीके का उपयोग करने में सक्षम नहीं होंगे। ।

— पिकपग

10

@pickypg लेकिन यदि इंटरफ़ेस को लागू करने वाला वर्ग पहले से ही किसी अन्य वर्ग का विस्तार करता है, तो आप इसे किसी अन्य वर्ग का विस्तार नहीं कर सकते। मुझे यह एक इंटरफ़ेस के लिए भ्रमित नहीं लगेगा जो केवल एक पैकेज के अंदर उपयोग किया जाता है।

— फ्लेममा

24

@ रेवलिन, -1, यह सवाल पेश करता है "एक इंटरफ़ेस का मतलब यह क्यों माना जाता है कि आप कक्षा के बाहर से क्या देख सकते हैं?" Java 8 पहले से ही इंटरफेस बॉडी को इंटरफेस में अनुमति देता है, इसलिए संरक्षित अमूर्त विधियों को भी अनुमति क्यों नहीं दी जाती है?

— Pacerier

8

मैं अक्सर इस स्पष्टीकरण को पढ़ता हूं, लेकिन यह गलत है IMHO। एक इंटरफ़ेस एक "मानक विनिमय प्रोटोकॉल" की तरह है, भले ही ओओपी, संचार एपीआई या हार्डवेयर के बारे में बात न हो। मेरे पीसी पर यूएसबी पोर्ट स्पष्ट रूप से एक सार्वजनिक इंटरफ़ेस है। लेकिन मेरे मेनबोर्ड पर पिन, जो एक की-लॉक केस के पीछे है, जो वैकल्पिक यूएसबी पोर्ट तक पहुंच प्रदान करते हैं, स्पष्ट रूप से एक "संरक्षित" इंटरफ़ेस है। फिर हमारे पास BIOS चिप है - जो एक मानकीकृत इंटरफ़ेस भी है, लेकिन इसे कभी भी किसी भी तरह से सार्वजनिक नहीं किया जाता है, केवल कुछ कंपनियां निजी में सटीक विवरण जानती हैं। तो, ज़ाहिर है, इंटरफेस किसी भी दृश्यता हो सकता है! OOP में क्यों नहीं?

— फू बार

55

यद्यपि अक्सर उद्धृत कारण यह है कि "इंटरफेस सार्वजनिक एपीआई को परिभाषित करते हैं", मुझे लगता है कि यह एक अति-सरलीकरण है। (और यह परिपत्र तर्क की "गंध" भी है।)

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

दरअसल, मुझे लगता है कि इंटरफ़ेस के सदस्यों को सार्वजनिक रूप से बनाने के पीछे तर्क का हिस्सा यह है कि यह जावा भाषा को सरल बनाता है :

स्पष्ट रूप से सार्वजनिक इंटरफ़ेस सदस्य प्रोग्रामर से निपटने के लिए सरल हैं। आपने कितनी बार कोड (कक्षाएं) देखी हैं जहां विधि अभिगम संशोधक यादृच्छिक रूप से प्रतीत होते हैं? बहुत सारे "साधारण" प्रोग्रामर को यह समझने में कठिनाई होती है कि जावा एब्स्ट्रेक्शन सीमाओं ¹ को कैसे प्रबंधित किया जाए । सार्वजनिक / संरक्षित / पैकेज-निजी को इंटरफेस में जोड़ना उनके लिए और भी कठिन हो जाता है।
अवैध रूप से सार्वजनिक इंटरफ़ेस सदस्य भाषा विनिर्देशन को सरल करते हैं ... और इसलिए जावा संकलक लेखकों के लिए कार्य, और जो लोग प्रतिबिंब एपीआई को लागू करते हैं।

यह सोचने की पंक्ति कि "इंटरफेस सार्वजनिक एपीआई को परिभाषित करते हैं" यकीनन सरल भाषा डिजाइन निर्णय का एक परिणाम (या विशेषता) है ... अन्य तरीके से नहीं। लेकिन वास्तव में, जावा डिजाइनरों के मन में समानांतर रूप से विचार की दो पंक्तियों का विकास हुआ।

किसी भी दर पर, JDK-8179193 में RFE के लिए आधिकारिक प्रतिक्रिया यह स्पष्ट करती है कि जावा डिजाइन टीम ने ^{2 का} फैसला किया है कि protectedइंटरफेस पर अनुमति देना थोड़ा वास्तविक लाभ के लिए जटिलता जोड़ता है। सबूत खोजने के लिए कुडोस से @skomisa ।

RFE में साक्ष्य मुद्दे को सुलझाता है। यह आधिकारिक कारण है कि क्यों नहीं जोड़ा गया है।

^{1 - बेशक, टॉप-गन प्रोग्रामर्स को इन चीजों से कोई कठिनाई नहीं है, और एक्सेस कंट्रोल सुविधाओं के समृद्ध पैलेट का स्वागत कर सकते हैं। लेकिन, क्या होता है जब उनके कोड को बनाए रखने के लिए किसी और को सौंप दिया जाता है?}

^{2 - आप उनके निर्णय या उनके बताए गए तर्क से असहमत हो सकते हैं लेकिन यह गलत है।}

— स्टीफन सी
स्रोत

21

मुझे यह कहना है कि इस सवाल को जावा 8. में डिफ़ॉल्ट तरीकों की शुरूआत के द्वारा फिर से खोला गया है। मैं अभी जिस प्रोजेक्ट पर काम कर रहा हूं, वह एक इंटरफेस की आधार प्रकृति के समान है, जिसका अर्थ कार्यान्वयन से अमूर्त इरादा है।

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

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

— माइकल ओबेरलिन
स्रोत

मैं 100% सहमत हूं। डिफ़ॉल्ट तरीकों की शुरुआत से पहले सार कक्षाएं एक समझदार विकल्प थीं। हालाँकि, कई सीमाओं पर उनके द्वारा की जाने वाली सीमाओं का अर्थ है कि वे परिपूर्ण नहीं हैं। डिफ़ॉल्ट तरीकों के साथ इंटरफेस आमतौर पर> = जेडीके 1.8 दुनिया में बेहतर विकल्प हैं, लेकिन क्योंकि वे राज्य को स्टोर नहीं कर सकते हैं वे राज्य को उजागर करने के लिए अन्य सार तरीकों को परिभाषित करने पर भरोसा करते हैं, जिसका अर्थ है कि राज्य को सार्वजनिक किया जाता है, जो हमेशा ऐसा नहीं होता है तुम्हें चाहिए।

— फ्रा जेरेमी क्रिएग

10

क्योंकि इंटरफेस सार्वजनिक एपीआई को परिभाषित करते हैं। जो कुछ भी संरक्षित है वह एक आंतरिक विवरण है जो एक इंटरफ़ेस में नहीं है।

आप संरक्षित अमूर्त विधियों के साथ अमूर्त कक्षाओं का उपयोग कर सकते हैं, लेकिन इंटरफेस सार्वजनिक तरीकों और सार्वजनिक स्थैतिक अंतिम क्षेत्रों तक सीमित हैं।

— सीन पैट्रिक फ्लोयड
स्रोत

5

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

— पचेरियर

1

जावा 8 के डिफ़ॉल्ट तरीकों के साथ अब और सच नहीं है।

— मारियो रॉसी

@MarioRossi और जावा 9 के निजी इंटरफ़ेस विधियों के साथ अब और सच नहीं है।

— skomisa

7

शायद, क्योंकि यह एक इंटरफ़ेस है , अर्थात यह ग्राहकों को यह बताने के लिए है कि वे उदाहरणों के साथ क्या कर सकते हैं, बजाय यह बताने के कि वे क्या कर सकते हैं।

— इंगो
स्रोत

1

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

— फ्रा जेरेमी क्रिएग

6

मुझे दृढ़ता से लगता है कि इंटरफेस को संरक्षित तरीकों की अनुमति देनी चाहिए; किसने कहा कि इंटरफेस को पूरी दुनिया में हर किसी को दिखना है? जैसा कि आपकी बात है कि यह "साधारण" (पढ़ें: अक्षम) प्रोग्रामर को भ्रमित कर सकता है: ओओपी का इतना हिस्सा वस्तुओं, कक्षाओं, पैकेजों आदि को ठीक से बनाने के बारे में है, अगर किसी प्रोग्रामर के पास यह सब ठीक से करने के साथ एक कठिन समय है, तो उसके पास है। बहुत बड़ी समस्या। जावा को उस प्रकार के लिए बनाया गया था ।

— IntelliData
स्रोत

इस सवाल का जवाब नहीं है।

— स्टीफन सी

5

यहाँ कई उत्तर यह बताने के लिए परिपत्र तर्क देते हैं कि इंटरफ़ेस के तरीकों की सुरक्षा क्यों नहीं की जा सकती है: ऐसा इसलिए है क्योंकि उन्हें सार्वजनिक होना है, इसलिए जाहिर है कि उन्हें संरक्षित नहीं किया जा सकता है!

यह कुछ भी नहीं समझाता है, लेकिन सौभाग्य से किसी ने कुछ साल पहले JDK बग के रूप में इंटरफेस में संरक्षित तरीकों के लिए एक वृद्धि का अनुरोध उठाया , जो इस मुद्दे पर कुछ प्रकाश डालता है:

इंटरफेस में संरक्षित तरीके: संकुल भर में साझा करें

चूंकि संशोधक जावा में सीमित हैं, इसलिए पैकेजों में तरीकों को साझा करने का एक तरीका सार्वजनिक तरीकों तक सीमित है। कभी-कभी एक विधि को सार्वजनिक करना खतरनाक होता है, लेकिन उचित संशोधक की कमी के कारण ऐसा होना चाहिए। मेरा समाधान इस सीमा से अधिक है।

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

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

इस तरह हम कुछ विशेष तरीकों को अच्छी तरह से ज्ञात पैकेजों में साझा कर सकते हैं।

और यह उस एन्हांसमेंट रिक्वेस्ट का जवाब है, जिसे स्टेटस के साथ बंद किया गया था Won't fix:

यह प्रस्ताव एक समस्या को हल करने का प्रयास करता है जो जटिलता और विशेष मामलों को थोड़ा वास्तविक लाभ के लिए जोड़ता है। इस समस्या को हल करने का एक विशिष्ट तरीका एक निजी वर्ग है जो एक सार्वजनिक इंटरफ़ेस लागू करता है। कार्यान्वयन के तरीके सार्वजनिक हैं, लेकिन एक निजी वर्ग के भीतर हैं, इसलिए वे निजी रहते हैं।

जावा 9 में शुरू होने वाला एक विकल्प कक्षाएं और विधियों को सार्वजनिक करने के लिए है, लेकिन एक मॉड्यूल के भीतर जो आम जनता को निर्यात किए जाने के बजाय विशिष्ट "मित्र" मॉड्यूल के लिए योग्य-निर्यात होता है।

तो उस बग रिपोर्ट से आधिकारिक takeaways हैं:

वर्तमान स्थिति बदलने वाली नहीं है; इंटरफेस कभी समर्थन protectedविधियों की संभावना नहीं है ।
protectedइंटरफेस में तरीकों का समर्थन नहीं करने का औचित्य यह है कि यह " थोड़ा वास्तविक लाभ के लिए जटिलता और विशेष मामलों को जोड़ता है "।
जावा 9 के बाद से तरीकों के लिए पैकेज स्तर तक पहुंच प्रदान करने के लिए एक वैकल्पिक दृष्टिकोण है। का प्रयोग करें जावा प्लेटफ़ॉर्म मॉड्यूल प्रणाली (JPMS) करने के लिए " " के बजाय आम जनता के लिए निर्यात किया जा रहा के मॉड्यूल दोस्त बना वर्गों और सार्वजनिक तरीकों, लेकिन एक मॉड्यूल है कि एक विशेष के लिए योग्य निर्यात है के भीतर " "।

— skomisa
स्रोत

4

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

— dm76
स्रोत

2

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

इंटरफ़ेस चर के बारे में कोड शैली से एक अंश , लेकिन फिर भी तरीकों पर लागू होता है:

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

— ख़ाकी
स्रोत

2

आंतरिक उप-केंद्रों की घोषणा करना एक अच्छा अभ्यास है, लेकिन आप अपने आंतरिक तरीकों को protectedजावा में एक इंटरफ़ेस के रूप में तकनीकी रूप से घोषित नहीं कर सकते ।

बेशक, आप आंतरिक उपयोग के लिए एक और इंटरफ़ेस बना सकते हैं जो सार्वजनिक इंटरफ़ेस का विस्तार करता है:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

आप InternalInterfaceपैकेज के अंदर इंटरफ़ेस का उपयोग कर सकते हैं , लेकिन आपको PublicInterface(सार्वजनिक विधियों में) किसी भी उपप्रकार को स्वीकार करना चाहिए :

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

पैकेज के बाहर उपयोगकर्ता PublicInterfaceबिना किसी समस्या के उपयोग कर सकते हैं ।

आमतौर पर प्रोग्रामर समान स्थितियों में अमूर्त कक्षाएं बनाते हैं। हालांकि, इस मामले में हम कई उत्तराधिकार के लाभ खो देते हैं।

— दविद होर्वाथ
स्रोत

1

पैकेज उपयोगकर्ताओं के बाहर YourPublicInterface.Internalभी उपयोग कर सकते हैं । नेस्टेड इंटरफेस सहित एक इंटरफेस में सब कुछ सार्वजनिक या publicकीवर्ड की अनुपस्थिति की परवाह किए बिना सार्वजनिक है ।

— ग्रेग रूलोफ्स

1

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

और यहां तक कि पैकेज परिदृश्य वास्तव में क्या इंटरफेस के बारे में नहीं है।

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

— biziclop
स्रोत

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

— सुपरकैट

0

संरक्षित विधियां हमेशा उप-वर्ग द्वारा ही सुलभ होती हैं, यदि उपवर्ग आधार वर्ग का विस्तार करता है।

इंटरफ़ेस के मामले में, उपवर्ग कभी भी इंटरफ़ेस का विस्तार नहीं करता है। यह इंटरफ़ेस को लागू करता है।

संरक्षित विधियां विस्तार के माध्यम से सुलभ हैं और कार्यान्वयन के साथ नहीं ।

— आफताब सिद्दीकी
स्रोत

क्या फर्क पड़ता है क्या कीवर्ड, इससे कोई फर्क नहीं पड़ता।

— एलेक्स78 191

0

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

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}

— स्टेफानोस कारगास
स्रोत

2

लेकिन निजी तरीके जो किसी को नहीं दिखेंगे, उन्हें इंटरफेस में अनुमति नहीं है।

— 1378 में एलेक्स78191

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

— एलेक्स78 191 14

तुम सही हो। जावा 9 के रूप में इंटरफेस में निजी तरीकों की अनुमति है। ये अमूर्त नहीं हो सकते हैं और इन्हें इंटरफ़ेस के भीतर लागू किया जाता है और मुख्य रूप से अन्य डिफ़ॉल्ट या स्थिर तरीकों (यदि वे स्वयं स्थिर हैं) द्वारा उपयोग किया जाता है।

— स्टेफानोस कारगास

1

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

— स्कोमीसा