एक इंटरफ़ेस दूसरे इंटरफ़ेस को लागू क्यों नहीं कर सकता है?


104

मेरा कहने का तात्पर्य है:

interface B {...}

interface A extends B {...} // allowed  

interface A implements B {...} // not allowed

मैं इसे googled और मैंने पाया इस :

implementsएक अंतरफलक के तरीकों के लिए एक कार्यान्वयन को परिभाषित करने को दर्शाता है। हालांकि इंटरफेस का कोई कार्यान्वयन नहीं है इसलिए यह संभव नहीं है।

हालाँकि, इंटरफ़ेस एक 100% अमूर्त वर्ग है, और एक अमूर्त वर्ग अपने तरीकों को लागू किए बिना इंटरफेस (100% अमूर्त वर्ग) को लागू कर सकता है। "इंटरफ़ेस" के रूप में परिभाषित होने पर क्या समस्या है?

विवरण में,

interface A {
    void methodA();
}

abstract class B implements A {} // we may not implement methodA() but allowed

class C extends B {
   void methodA(){}
} 

interface B implements A {} // not allowed. 
//however, interface B = %100 abstract class B

जवाबों:


110

implementsलागू करने का मतलब है, जब लागू interfaceकरने के लिए सिर्फ घोषणा करने के interfaceलिए है।

एक 100% abstract classकार्यात्मक रूप से एक समान है, interfaceलेकिन इसका कार्यान्वयन भी हो सकता है यदि आप चाहें (इस मामले में यह 100% नहीं रहेगा abstract), तो JVM के दृष्टिकोण से वे अलग-अलग चीजें हैं।

इसके अलावा एक 100% अमूर्त वर्ग में सदस्य चर में कोई भी एक्सेस क्वालिफायर हो सकता है, जहां इंटरफ़ेस में वे निहित हैं public static final


8
जावा 8 के रूप में, इंटरफेस में डिफ़ॉल्ट तरीके हो सकते हैं, जिससे वे उस संबंध में एब्सट्रैक्ट क्लासेस के समान हो जाते हैं।
forresthopkinsa

4
अंतिम वाक्य के लिए धन्यवाद!
ताओ झांग

24

implementsइसका मतलब है कि एक व्यवहार abstractविधियों के लिए परिभाषित किया जाएगा (स्पष्ट रूप से अमूर्त वर्गों को छोड़कर), आप कार्यान्वयन को परिभाषित करते हैं।

extends इसका मतलब है कि एक व्यवहार विरासत में मिला है।

इंटरफेस के साथ यह कहना संभव है कि एक इंटरफ़ेस में एक जैसा व्यवहार होना चाहिए, एक वास्तविक कार्यान्वयन भी नहीं है। यही कारण है कि यह एक इंटरफ़ेस के लिए extendsइसे लागू करने के बजाय दूसरे इंटरफ़ेस के लिए अधिक समझ में आता है।


एक साइड नोट पर, याद रखें कि भले ही एक abstractवर्ग abstractतरीकों को परिभाषित कर सकता है (एक इंटरफ़ेस जिस तरह से करता है), यह अभी भी एक वर्ग है और अभी भी विरासत में मिला है (विस्तारित) और कार्यान्वित नहीं किया गया है।


4

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


यदि "Y एक्स का विस्तार करता है" और इसे सील नहीं किया जाता है, तो एक और प्रकार "जेड" होना संभव है जो "वाई" को विस्तारित करता है। यह सच होगा कि X एक इंटरफ़ेस है या एक क्लास। यदि "डब्ल्यू इम्प्लीमेंट्स एक्स", हालांकि, तो "वी इम्प्लीमेंट्स डब्ल्यू" होना संभव नहीं है। तथ्य यह है कि "फैली हुई" को "जंजीर" किया जा सकता है और "लागू करना" अलग-अलग कीवर्ड होने के एक अच्छे कारण की तरह नहीं लग सकता है।
सुपरकैट

2

हालांकि, इंटरफ़ेस 100% अमूर्त वर्ग है और अमूर्त वर्ग अपने तरीकों को लागू किए बिना इंटरफ़ेस (100% अमूर्त वर्ग) को लागू कर सकता है। "इंटरफ़ेस" के रूप में परिभाषित होने पर क्या समस्या है?

यह केवल सम्मेलन का विषय है। जावा भाषा के लेखकों ने फैसला किया कि "विस्तार" इस ​​रिश्ते का वर्णन करने का सबसे अच्छा तरीका है, इसलिए हम सभी इसका उपयोग करते हैं।

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

दूसरों के राज्य के रूप में, "लागू" पर "विस्तार" चुनने के लिए अच्छे कारण हैं।


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

1

आशा है कि यह आपको मेरे कॉलेज के दौरान ऊप्स (कोर जावा) में जो कुछ सीखा है, उससे आपको थोड़ी मदद मिलेगी।

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

नीचे एक उदाहरण दिया गया है, यह मेरी समझ है और मैंने उफ़ में क्या सीखा है।

interface ParentInterface{  
        void myMethod();  
}  

interface SubInterface extends ParentInterface{  
        void anotherMethod();  
}  

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

public interface Dog
{
    public boolean Barks();

    public boolean isGoldenRetriever();
}

अब, यदि कोई वर्ग इस इंटरफ़ेस को लागू करने के लिए था, तो यह ऐसा होगा:

public class SomeClass implements Dog
{
    public boolean Barks{
    // method definition here

    }

    public boolean isGoldenRetriever{
    // method definition here
    }
}

और अगर एक अमूर्त वर्ग में कुछ सार फ़ंक्शन परिभाषित और घोषित होते हैं और आप उन फ़ंक्शन को परिभाषित करना चाहते हैं या आप कह सकते हैं कि वे फ़ंक्शन लागू कर सकते हैं तो आप उस वर्ग का विस्तार करते हैं क्योंकि अमूर्त वर्ग को केवल बढ़ाया जा सकता है। यहाँ नीचे उदाहरण है।

public abstract class MyAbstractClass {

    public abstract void abstractMethod();
}

यहाँ एक उदाहरण है MyAbstractClass का उपवर्ग:

public class MySubClass extends MyAbstractClass {

    public void abstractMethod() {
        System.out.println("My method implementation");
    }
}

0

इंटरफ़ेस एक अमूर्त की तरह है जो कोई कार्यक्षमता प्रदान नहीं कर रहा है। इसलिए मैं 'अमल' नहीं करता लेकिन अन्य अमूर्तताओं या इंटरफेस का विस्तार करता हूं।


-6

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.