इंटरफेस कौन बढ़ाता है? और क्यों?


20

AFAIK, मेरी कक्षा extendsअभिभावक वर्ग और implementsइंटरफेस। लेकिन मैं ऐसी स्थिति में दौड़ता हूं, जहां मैं उपयोग नहीं कर सकता implements SomeInterface। यह एक सामान्य प्रकार की घोषणा है। उदाहरण के लिए:

public interface CallsForGrow {...}

public class GrowingArrayList <T implements CallsForGrow>  // BAD, won't work!
                              extends ArrayList<T> 

यहाँ का उपयोग implementsकरना वाक्यगत रूप से निषिद्ध है। मैंने पहले सोचा, कि <> के अंदर इंटरफेस का उपयोग करना बिल्कुल मना है, लेकिन नहीं। यह संभव है, मुझे केवल extendsइसके बजाय उपयोग करना है implements। नतीजतन, मैं एक इंटरफ़ेस "विस्तारित" कर रहा हूं। यह एक और उदाहरण काम करता है:

public interface CallsForGrow {...}

public class GrowingArrayList <T extends CallsForGrow>  // this works!
                              extends ArrayList<T> 

मेरे लिए यह एक वाक्यात्मक असंगति के रूप में लगता है। लेकिन शायद मैं जावा 6 के कुछ चालाकों को नहीं समझता? क्या अन्य स्थान हैं जहां मुझे इंटरफेस का विस्तार करना चाहिए? क्या इंटरफ़ेस, जिसका मेरा मतलब विस्तार करना है, कुछ विशेष विशेषताएं हैं?

जवाबों:


25

सामान्य प्रकार के चर के मामले में कंपाइलर वास्तव में परवाह नहीं करता है यदि Tएक वर्ग, एक इंटरफ़ेस, एक एनम या एनोटेशन है। सभी इसकी परवाह करते हैं कि यह उप-और सुपर-प्रकारों के दिए गए सेट के साथ एक प्रकार है।

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

एक पल के लिए मान लें कि आपको implementsयहां लिखना है, तो आपको enumमूल्यों के लिए एक अलग सिंटैक्स की आवश्यकता होगी (केवल लिखने के बजाय <E extends Enum<E>>) और एनोटेशन (जिसे आप आसानी से उपयोग करने की घोषणा कर सकते हैं <A extends Annotation>)।

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

यह भी ध्यान दें कि वहाँ एक और जगह है जहाँ आप extendsइंटरफेस के साथ उपयोग करते हैं:

interface A {
}

interface B extends A {
}

इस बिंदु पर implementsगलत होगा, क्योंकि B लागू नहीं होता है A


यदि हम आपके लॉजिक्स का उपयोग करेंगे, तो हमें हमेशा ' न केवल इनइंटरफेस' का उपयोग करना चाहिए , न केवल जेनरिक में।
गंगानुस

2
@ गैंग्नस: नहीं, क्योंकि कार्यान्वयनकर्ता के बीच एक ठोस अंतर होता है extendsऔर implements, यह तब होता है जब इस मुद्दे को शुद्ध प्रकार-प्रणाली के नजरिए से देखा जाता है, ताकि कोई अंतर न हो।
जोकिम सॉयर

1
क्षमा करें, मुझे आपका विचार समझ नहीं आ रहा है। --1। हमें एक मामले में "शुद्ध टाइप-सिस्टम परिप्रेक्ष्य" का उपयोग क्यों करना चाहिए और दूसरे में नहीं? -2। इन अलग-अलग जगहों पर वाक्य-रचना की माँग क्यों बदल जाती है? क्या आप इसे समझा सकते हैं, कृपया। उत्तर में, यदि संभव हो तो।
गंगानुस

1
@ गंगनुस: कौन कहता है कि Tएक वर्ग है? Tएक इंटरफ़ेस प्रकार या एक enumप्रकार का संदर्भ दे सकता है ।
जोकिम सॉयर

1
C # से आने पर, यह पूरी चर्चा हास्यास्पद है। हम एक प्रकार के सुपरपाइप के साथ निरूपित करते हैं :। और कवर के तहत, एक इंटरफ़ेस है और हमेशा एक अमूर्त वर्ग रहा है जिसमें केवल अनपेक्षित वर्चुअल ( abstract) सदस्यों की कमी होती है , ताकि एकाधिक उत्तराधिकार के लिए अनुमति दी जा सके। वस्तुतः कोई अंतर नहीं है implementsऔर extends। वे दोनों को एक ही शब्द ( extends) या कुछ मनमाने प्रतीक ( :) से बदला जा सकता है और कुछ भी नहीं खोया जाएगा।
सारा

5

जब जावा 5, और विशेष रूप से जेनरिक में, शुरू में डेवलपर्स के लिए उपलब्ध कराया गया था जिन्होंने एक ब्याज दर्ज किया था, तो वाक्य रचना काफी अलग थी। के बजाय Set<? extends Foo>और Set<? super Bar>यह था Set<+Foo>और Set<-Foo>। हालाँकि, प्रतिक्रिया यह थी कि यह स्पष्ट नहीं +था कि क्या अधिक विशिष्ट या व्यापक (अधिक कक्षाएं) हैं । सूर्य ने वाक्य-विन्यास को बदलकर उस प्रतिक्रिया का जवाब दिया, लेकिन नए खोजशब्दों को पेश नहीं करने की अड़चन के भीतर, जो कि पश्चगामी अनुकूलता के लिए एक समस्या थी।

नतीजा यह है कि न तो बिल्कुल स्वाभाविक है। जैसा कि आप निरीक्षण extendsकरते हैं, कक्षाओं के "विस्तारित" इंटरफेस की बात करने के लिए अतिभारित है, जो अन्य संदर्भों में उपयोग की जाने वाली भाषा नहीं है; और superइसका मतलब है कि "एक सुपरक्लास है", जो कि खोजशब्द द्वारा पहले व्यक्त किए गए संबंध की विपरीत दिशा है, अर्थात सुपरक्लास का जिक्र करते हुए अतिभारित है।

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


+1। मैं देखता हूं और सहमत हूं। लेकिन जोआचिम सॉयर ने मेरी गलत सोच को पाया है कि टी जरूरी एक वर्ग है। तो, जवाब उसका है। आपकी समझ एक (या 2) मंजिला उच्च :-) है। मेरी समस्या अधिक आदिम थी। मेरे विकास के लिए वैसे भी धन्यवाद।
गंगानुस

2

इस तरह के सिंटैक्स को अनुमति देने और प्रतिबंधित करने दोनों में नुकसान हैं, और अनुमति देने वालों की संख्या कहीं अधिक है।

जस्ट थिंक आफ इट।

इंटरफ़ेस और कार्यान्वयन का अलगाव मौलिक प्रोग्रामिंग मुहावरों में से एक है। उसके कारण, वाक्यविन्यास "इंटरफ़ेस कुछ को लागू करने" की अनुमति देता है और ऑपरेंड के गुणन को निरूपित करने के लिए प्लस साइन का उपयोग करने के रूप में बुरा होगा ।


ठीक है। इसलिए, मुझे वास्तव में कुछ समझ नहीं आ रहा है। मैंने इसे बहुत संभावित माना। लेकिन आपने 'समस्या को पूरी तरह माफ कर दिया'। टी एक वर्ग का प्रतिनिधित्व है। क्यों एक जगह मैं टी एक्सटेंड्स का इस्तेमाल करता हूं और दूसरे टी इम्प्लीमेंट्स में?
गंगानुस

@Gangnus आपके द्वारा प्रदान किए गए उदाहरण में टाइप पैरामीटर को संदर्भित करता है जो जरूरी नहीं कि एक वर्ग है - जोकिम ने आपको पहले ही बताया था । की अनुमति दे औजार इसके लिए एक ही गंदगी मैंने कहा करने के लिए नेतृत्व करेंगे
कुटकी

हां, मैंने उनकी टिप्पणी पहले ही देख ली है। इसे उत्तर के रूप में अंकित किया जाएगा। तब तक जब तक तुम दोनों मेरा धन्यवाद और +1 करो।
गंगानुस

-1

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


2
आपका जवाब ओपी की चिंताओं को कैसे संबोधित करता है? कृपया अधिक स्पष्ट होने के लिए अपने उत्तर को संपादित करें।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.