जावा सार इंटरफ़ेस

Question

एक उदाहरण पर विचार करें (जो जावा में संकलित है)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

एक इंटरफ़ेस को "घोषित" सार के लिए क्यों आवश्यक है? क्या अन्य नियम हैं जो अमूर्त इंटरफ़ेस के साथ लागू होते हैं?

---

अंत में: यदि abstractअप्रचलित है, तो इसे जावा में क्यों शामिल किया गया है? क्या अमूर्त इंटरफ़ेस के लिए एक इतिहास है?

Comments

एक

— थिलो

" अंत में: .... " भाग पर विचार करते हुए कोई डुप्लिकेट नहीं ।

— aioobe

यह संबंधित प्रश्न एक वास्तविक उदाहरण उद्धृत करता है: stackoverflow.com/questions/4380796/…

— Raedwald

जब आप 'इंटरफ़ेस निकालते हैं' तो ग्रहण डिफ़ॉल्ट रूप से 'अमूर्त' क्यों जोड़ता है?

— मोदीफायर

@ModdyFire, कृपया विस्तृत करें?

— बुहाके सिंडी

Answer 1

एक इंटरफ़ेस को "घोषित" सार के लिए क्यों आवश्यक है?

यह।

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

इंटरफेस और उनके तरीके निहित हैं abstractऔर उस संशोधक को जोड़ने से कोई फर्क नहीं पड़ता है।

क्या अन्य नियम हैं जो अमूर्त इंटरफ़ेस के साथ लागू होते हैं?

नहीं, समान नियम लागू होते हैं। विधि को किसी भी (ठोस) लागू करने वाले वर्ग द्वारा लागू किया जाना चाहिए।

यदि सार अप्रचलित है, तो इसे जावा में क्यों शामिल किया गया है? क्या अमूर्त इंटरफ़ेस के लिए एक इतिहास है?

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

ठीक है, आगे भी खुदाई करना ... कई टूटे हुए लिंक को मारने के बाद, मैं मूल ओक 0.2 विनिर्देश (या "मैनुअल") की एक प्रति खोजने में कामयाब रहा । काफी दिलचस्प पढ़ें मुझे कहना होगा, और कुल मिलाकर केवल 38 पृष्ठ! :-)

धारा 5, इंटरफेस के तहत, यह निम्नलिखित उदाहरण प्रदान करता है:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

और मार्जिन में यह कहता है

भविष्य में, इंटरफेस में तरीकों की घोषणा का "= 0" हिस्सा दूर जा सकता है।

मान =0लिया गया कि abstractकीवर्ड द्वारा प्रतिस्थापित कर दिया गया है , मुझे संदेह है कि abstractइंटरफ़ेस विधियों के लिए कुछ बिंदु अनिवार्य था!

---

संबंधित लेख: जावा: सार इंटरफेस और सार इंटरफ़ेस तरीके

Comments

लेकिन अमूर्त ही अप्रचलित नहीं है, या? यह इंटरफेस के लिए अप्रचलित है, लेकिन अभी भी अमूर्त वर्ग और विधियां हैं।

— user85421

धन्यवाद;; मुझे लगता है कि मैं अंत abstractमें इंटरफ़ेस विधियों के सामने अनुमति देने के लिए मूल को नीचे कर दिया ।

— aioobe

वाह। तो यह अप्रचलित है "डिजाइन द्वारा"। उन JLS डिजाइनरों को वास्तव में हमेशा कुछ टूटने का डर था, यहां तक ​​कि उन चीजों को भी तोड़ना जो कभी भी जारी नहीं हुई ... :-)

— लुकास एडर

@aioobe, आप Google वेब क्रॉलर होने चाहिए जिनके बारे में हम नहीं जानते ... lol

— Buhake Sindi

Btw। "सार्वजनिक" एक इंटरफ़ेस घोषणा में तरीकों पर भी आवश्यक नहीं है ... वे हमेशा सार्वजनिक होते हैं।

— आरईसी

Answer 2

यह आवश्यक नहीं है, यह वैकल्पिक है, बस publicइंटरफ़ेस तरीकों पर।

इस पर JLS देखें:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 सार इंटरफेस हर इंटरफ़ेस संक्षेप में सार है। यह संशोधक अप्रचलित है और इसका उपयोग नए कार्यक्रमों में नहीं किया जाना चाहिए।

तथा

9.4 सार विधि घोषणाएँ

[...]

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

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

Comments

JLS के लिए: यह अनुमति है, लेकिन दृढ़ता से हतोत्साहित किया जाता है, शैली की बात के रूप में, दो अर्थों को एक ही अर्थ के साथ लिखने के लिए और लगभग सटीक शब्दों में एक-दूसरे के साथ ...

— n611x007

Answer 3

इंटरफ़ेस सार घोषित करने के लिए आवश्यक नहीं है।

जैसे उन सभी तरीकों को सार्वजनिक घोषित करना (जो कि वे पहले से ही यदि इंटरफ़ेस सार्वजनिक है) या सार (जो वे पहले से ही एक इंटरफ़ेस में हैं) बेमानी है।

हालांकि कोई भी आपको रोक नहीं रहा है।

अन्य चीजें जिन्हें आप स्पष्ट रूप से बता सकते हैं, लेकिन इसकी आवश्यकता नहीं है:

• एक निर्माणकर्ता की पहली पंक्ति पर सुपर () कॉल करें
• extends Object
• विरासत में मिला इंटरफेस लागू करें

क्या अन्य नियम हैं जो अमूर्त इंटरफ़ेस के साथ लागू होते हैं?

एक इंटरफ़ेस पहले से ही "सार" है। उस कीवर्ड को फिर से लागू करने से कोई फर्क नहीं पड़ता।

Comments

जाहिरा तौर पर, तरीके भी सार्वजनिक हैं अगर इंटरफ़ेस स्वयं पैकेज-निजी है।

— थिलो

Answer 4

विदित हो कि वसंत ऋतु में इसका गैर शैक्षणिक अर्थ होता है। सार इंटरफ़ेस डेवलपर के लिए इसका उपयोग न करने के लिए एक चेतावनी है@Autowired । मुझे उम्मीद है कि वसंत / ग्रहण @Autowiredइस विशेषता को देखेगा और इस तरह के उपयोगों के बारे में चेतावनी / असफलता देगा।

एक वास्तविक उदाहरण: @ सेवा के तहत @ सेवा के लिए @Repository को एक ही मूल तरीकों का उपयोग करने की आवश्यकता है, हालांकि उन्हें अलग-अलग इंटरफेस का उपयोग करना चाहिए जो इस सार इंटरफ़ेस का विस्तार करता है @Autowired। (मैं इसे XXXSpec इंटरफ़ेस कहता हूं)

Comments

+1 अच्छा हिट, मैं व्यापक रूप से गैर-निष्क्रियनीय सत्रबिन इंजेक्शन के पृथक्करण के लिए देखा। शायद मैं एक नियम के लिए फाइबग / चेकस्टाइल का उपयोग कर सकता हूं ....

— ग्रिम

Answer 5

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

[जावा लैंग्वेज स्पेसिफिकेशन - 9.1.1.1 abstract इंटरफेस]

यह भी ध्यान दें कि इंटरफ़ेस सदस्य तरीके निहित हैं public abstract।
[जावा लैंग्वेज स्पेसिफिकेशन - 9.2 इंटरफ़ेस सदस्य]

उन संशोधक क्यों निहित हैं? कोई अन्य संशोधक नहीं है (यहां तक ​​कि ' कोई संशोधक ' -मोडिफायर भी नहीं ) जो यहां उपयोगी होगा, इसलिए आपको इसे स्पष्ट रूप से लिखना नहीं होगा।

Answer 6

यह आवश्यक नहीं है। यह भाषा की एक विचित्रता है।

Answer 7

यह आवश्यक नहीं है, क्योंकि इंटरफेस डिफॉल्ट एब्सट्रैक्ट के होते हैं क्योंकि एक इंटरफेस में सभी तरीके अमूर्त होते हैं।

Answer 8

एक अमूर्त इंटरफ़ेस उतना बेमानी नहीं है जितना हर कोई कह रहा है, सिद्धांत में कम से कम।

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

उदाहरण:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

आप MyBaseInterface, केवल अन्य दो, MMyDog और MyBoat को लागू करने के लिए एक वर्ग नहीं चाहते हैं, लेकिन दोनों इंटरफेस MyBaseInterface इंटरफ़ेस को साझा करते हैं, इसलिए एक 'नाम' संपत्ति है।

मुझे पता है कि यह थोड़े अकादमिक है, लेकिन मुझे लगा कि कुछ दिलचस्प लग सकते हैं। :-)

यह वास्तव में इस मामले में केवल एक 'मार्कर' है, इंटरफ़ेस के कार्यान्वयनकर्ताओं को संकेत देने के लिए जिसे यह अपने आप लागू नहीं किया गया था। मुझे एक संकलक को इंगित करना चाहिए (कम से कम सूर्य / ओरा 1.6 मैंने इसे आज़माया) एक वर्ग को संकलित करता है जो एक सार इंटरफ़ेस को लागू करता है।

Comments

मेरा मानना ​​है कि आपने मेरे सवाल को बिल्कुल गलत समझा।

— बुहके सिंडी

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

— ब्लेडकॉडर

Answer 9

वैसे 'एब्सट्रैक्ट इंटरफेस' एक लेक्सिकल कंस्ट्रक्शन है: http://en.wikipedia.org/wiki/Lexical_analysis ।

यह संकलक द्वारा आवश्यक है, आप भी लिख सकते हैं interface।

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

`इंटरफ़ेस का सार कुछ अमूर्त अवधारणा (विचार / विचार / उच्च क्रम सोच आदि) को पकड़ने के लिए है, जिसका कार्यान्वयन अलग-अलग हो सकता है ... अर्थात, कई कार्यान्वयन हो सकते हैं।

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

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

यदि आपका ठोस वर्ग सभी विशेषताओं को लागू नहीं करता है तो यह फिर से अमूर्त हो जाता है क्योंकि आपके पास अपने विचार या विचार या अमूर्तता का कार्यान्वयन होता है लेकिन यह पूरा नहीं होता है, आप इसे abstractकक्षा द्वारा निर्दिष्ट करते हैं ।

एक ठोस वर्ग एक वर्ग / वर्गों का समूह होगा जो पूरी तरह से उस अमूर्तता को पकड़ लेगा जिसे आप कक्षा XYZ पर कब्जा करने की कोशिश कर रहे हैं।

तो पैटर्न है

Interface--->Abstract class/Abstract classes(depends)-->Concrete class

Comments

यह उत्तर मेरे प्रश्न का उत्तर नहीं देता है। इसके अलावा "It seams like you are new to Java। वास्तव में?

— बुहके सिंडी

"अमूर्त अप्रचलित है"

— मनीष

(1) "एब्सट्रैक्ट अप्रचलित है" -> अगर वे इसे हटा देते हैं और कंपाइलर इसे पहचानना बंद कर देता है तो "अमूर्त इंटरफ़ेस" के पिछले वर्जन के कोड कोड का नए वर्जन में उपयोग नहीं होगा .. उन्हें बैकवर्ड कम्पेटिबिलिटी बनाए रखने की जरूरत है। जब आप सार इंटरफेस को परिभाषित करते हैं, तो इंटरफ़ेस कीवर्ड का अर्थ "सार" के साथ अटक जाता है, जो कि अनुभवी प्रोग्रामर के लिए बहुत क्लीनर संस्करण है, जैसे कि उन्होंने शॉर्टकट "इंटरफ़ेस" प्रदान किया है .. आपका प्रश्न i = i + 1 == के समान है > i ++ .. चुनाव आपका है कि आप क्या चुनते हैं: D

— मनीष

स्वीकृत उत्तर को देखें। मुझे पता abstractहै कि इंटरफ़ेस में अप्रचलित है। मैं जानना चाहता था कि यह अभी भी स्वीकार्य क्यों है और abstractइंटरफ़ेस के पीछे का इतिहास क्या है । आप मुझे सार बनाम इंटरफ़ेस पर जावा 101 गाइड दे रहे हैं।

— बुहके सिंडी

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

— लोरेन का मार्कीस