इंटरफ़ेस और अमूर्त वर्ग के बीच अंतर क्या है?

Question

इंटरफ़ेस और अमूर्त वर्ग के बीच वास्तव में क्या अंतर है?

Comments

यह एक अत्यंत सामान्य साक्षात्कार प्रश्न है। यह आश्चर्यजनक है क्योंकि अन्य चीजों की तुलना में एक अमूर्त वर्ग शायद ही कभी समाधान में उपयोग किया जाता है। आपके प्रश्न ने मुझे Safraz की मदद की है।

— कट्टो

यह सवाल भी मदद की इंटरफेस अवधारणा को समझने की हो सकती है stackoverflow.com/q/8531292/1055241

— gprathour

मैंने PHP टैग को इस प्रश्न के रूप में निकाल दिया है, क्योंकि लगभग कोई भी उत्तर विशिष्ट भाषा नहीं है, और प्रश्न स्वयं भाषा विशिष्ट नहीं है।

— ब्राइस

सी ++ में दिन में वापस एक इंटरफ़ेस एक शुद्ध सार आधार वर्ग है जिसमें सभी विधि कार्यान्वयन हैं। 0. यदि कोई एकल विधि = 0 नहीं थी, तो इसका कार्यान्वयन है और सार आधार अब शुद्ध नहीं है, और अब कोई इंटरफ़ेस नहीं है । मुझे लगता है कि वीएमटी में अप्रत्यक्ष रूप से कम होता है जब कई विरासत केवल शुद्ध सार आधारों का उपयोग करते हैं, लेकिन मुझे याद नहीं है कि वे अब कैसे दिखते हैं, बहुत लंबा है।

— जिम

Answer 1

इंटरफेस

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

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

उदाहरण के लिए (छद्म कोड):

// I say all motor vehicles should look like this:
interface MotorVehicle
{
    void run();

    int getFuel();
}

// My team mate complies and writes vehicle looking that way
class Car implements MotorVehicle
{

    int fuel;

    void run()
    {
        print("Wrroooooooom");
    }


    int getFuel()
    {
        return this.fuel;
    }
}

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

---

सार वर्ग

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

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

उदाहरण के लिए:

// I say all motor vehicles should look like this:
abstract class MotorVehicle
{

    int fuel;

    // They ALL have fuel, so lets implement this for everybody.
    int getFuel()
    {
         return this.fuel;
    }

    // That can be very different, force them to provide their
    // own implementation.
    abstract void run();
}

// My teammate complies and writes vehicle looking that way
class Car extends MotorVehicle
{
    void run()
    {
        print("Wrroooooooom");
    }
}

---

कार्यान्वयन

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

जावा में, इस नियम को दृढ़ता से लागू किया गया है, जबकि PHP में, इंटरफेस अमूर्त वर्ग हैं जिनकी कोई विधि घोषित नहीं की गई है।

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

प्रोग्रामिंग के साथ हमेशा की तरह, सिद्धांत, अभ्यास और किसी अन्य भाषा में अभ्यास :-)

Comments

इंटरफेस के बारे में मुख्य बिंदु इतना नहीं है कि वे कहते हैं कि एक वर्ग क्या करता है, लेकिन उन वस्तुओं को अनुमति देता है जो एक Wizzler की आवश्यकता के लिए खुद को उपयोगी बनाने के लिए Wizzle कर सकते हैं। ध्यान दें कि कई मामलों में न तो वह व्यक्ति जो Wizzle लिखता है, और न ही वह व्यक्ति जिसे Wizzler की आवश्यकता है, वह इंटरफ़ेस लिखने वाला व्यक्ति होगा।

— सुपरकैट

मुझे नहीं लगता कि सीपीयू की खपत इंटरफेस पर हाइलाइट के योग्य बिंदु है।

— डैन लूग

@ ई-सिटिस क्या आप सीपीयू के उपयोग पर अपनी बात समझा सकते हैं? अमूर्त वर्ग एक वर्ग होने के कारण सीपीयू उपयोग में वृद्धि क्यों करता है? आप यहाँ किस प्रकार की खोज की बात कर रहे हैं?

— Geek

@ e-satis Java 8 के साथ, आप डिफ़ॉल्ट तरीकों को उन इंटरफेस में परिभाषित कर सकते हैं जो अमूर्त कक्षाओं में गैर-अमूर्त विधियों के बराबर हैं। इस जोड़ के साथ, मैं अब अमूर्त वर्गों और इंटरफ़ेस के बीच वास्तविक अंतर को नहीं देख सकता हूं इसके अलावा मुझे इंटरफेस का उपयोग करना चाहिए क्योंकि कक्षाएं कई इंटरफेस को लागू कर सकती हैं लेकिन केवल एक वर्ग को विरासत में प्राप्त कर सकती हैं

— ओजेन

मुझे लगता है कि दोनों के बीच तुलना interfaceऔर classसे Head First Javaज्वलंत है किA class defines who you are, and an interface tells what roles you could play

— LittleLittleQ

Answer 2

एक सार वर्ग और एक इंटरफ़ेस के बीच मुख्य तकनीकी अंतर हैं:

• अमूर्त वर्गों में स्थिरांक, सदस्य, विधि स्टब्स (शरीर के बिना तरीके) और परिभाषित तरीके हो सकते हैं, जबकि इंटरफेस में केवल स्थिरांक और विधियाँ स्टब्स हो सकते हैं ।

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

• जब एक अमूर्त कक्षा विरासत में मिलती है, तो एक ठोस बाल वर्ग को अमूर्त विधियों को परिभाषित करना चाहिए , जबकि एक अमूर्त वर्ग एक और अमूर्त वर्ग का विस्तार कर सकता है और मूल कक्षा से अमूर्त विधियों को परिभाषित करने की आवश्यकता नहीं है।

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

• एक बच्चा वर्ग केवल एक ही वर्ग (अमूर्त या ठोस) का विस्तार कर सकता है, जबकि एक इंटरफ़ेस विस्तार कर सकता है या एक वर्ग कई अन्य इंटरफेस को लागू कर सकता है ।

• एक बच्चा वर्ग समान या कम प्रतिबंधात्मक दृश्यता के साथ अमूर्त विधियों को परिभाषित कर सकता है , जबकि एक इंटरफ़ेस को लागू करने वाले वर्ग को सटीक समान दृश्यता (सार्वजनिक) के साथ तरीकों को परिभाषित करना होगा।

Comments

मुझे लगता है कि यह सबसे अच्छा जवाब है क्योंकि यह सभी प्रमुख अंतरों पर प्रकाश डालता है। एक उदाहरण वास्तव में आवश्यक नहीं है।

— जोशुआ के

और आम तौर पर कक्षाओं के साथ आप अमूर्त वर्गों के विपरीत किसी वस्तु को तत्काल कर सकते हैं, जो CANNOTकि तत्काल होती है।

— SASM

मुझे लगा कि इंटरफ़ेस को लागू करने वाले एक वर्ग को इंटरफ़ेस में सभी तरीकों को परिभाषित करने की आवश्यकता है?

— जियाज़ी यूजर

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

— जस्टिन जॉनसन

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

— निक

Answer 3

एक इंटरफ़ेस में केवल कार्यक्षमता की परिभाषा / हस्ताक्षर शामिल हैं, और अगर हमारे पास कुछ सामान्य कार्यक्षमता के साथ-साथ सामान्य हस्ताक्षर भी हैं, तो हमें एक सार वर्ग का उपयोग करने की आवश्यकता है। अमूर्त वर्ग का उपयोग करके, हम व्यवहार और साथ ही कार्यक्षमता दोनों को एक ही समय में प्रदान कर सकते हैं। अमूर्त वर्ग को प्राप्त करने वाला एक अन्य डेवलपर इस कार्यक्षमता का आसानी से उपयोग कर सकता है, क्योंकि उन्हें केवल रिक्त स्थान भरने की आवश्यकता होगी।

से लिया गया:

http://www.dotnetbull.com/2011/11/difference-between-abstract-class-and.html

http://www.dotnetbull.com/2011/11/what-is-abstract-class-in-c-net.html http://www.dotnetbull.com/2011/11/what-is-interface-in -c-net.html

Comments

आपको यह कहने की ज़रूरत है कि यह किस भाषा पर लागू होता है ("सार वर्ग एकाधिक विरासत का समर्थन नहीं करता है" सार्वभौमिक रूप से सच होने से बहुत दूर है)

— बेन वायगेट

अंतिम तुलना तालिका के अनुसार भ्रामक है! इंटरफ़ेस में विधियाँ स्थिर नहीं हो सकती हैं, लेकिन चर स्थिर अंतिम हैं अमूर्त वर्ग में कार्यान्वित विधियाँ स्थिर हो सकती हैं

— realPK

इंटरफ़ेस का सदस्य स्थिर अंतिम होना चाहिए। अंतिम कथन गलत है।

— जवाद ज़ेब

मुझे लगता है कि इस उत्तर में "कार्यक्षमता" का अर्थ है "कार्यान्वयन।" निश्चित नहीं है कि "व्यवहार" का क्या अर्थ है - शायद "हस्ताक्षर"?

— लार्स

यहां लक्षित प्रोग्रामिंग भाषा क्या है? सी#?

— पीटर मोर्टेंसन

Answer 4

एक स्पष्टीकरण यहां पाया जा सकता है: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter-Prtern.htm

एक अमूर्त वर्ग एक ऐसा वर्ग है जो केवल प्रोग्रामर द्वारा आंशिक रूप से लागू किया जाता है। इसमें एक या अधिक सार विधियाँ हो सकती हैं। एक अमूर्त विधि केवल एक फ़ंक्शन परिभाषा है जो प्रोग्रामर को यह बताने के लिए कार्य करती है कि विधि को एक बच्चे की कक्षा में लागू किया जाना चाहिए।

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

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

Comments

यह सबसे सही उत्तर है, क्योंकि PHP इंटरफेस अन्य भाषाओं से भिन्न होते हैं, क्योंकि PHP इंटरफेस हुड के तहत अमूर्त वर्ग होते हैं, जबकि अन्य भाषाओं के इंटरफेस हस्ताक्षर होते हैं जो कक्षाओं से मेल खाना चाहिए। वे तब तक ही व्यवहार करते हैं जब तक कि कोई त्रुटि न हो।

— तोर वलामो

सच है, PHP के लिए यह वास्तविक सबसे अच्छा anwser है। लेकिन साधारण स्निपेट की तुलना में टेक्स्ट ब्लॉब से प्राप्त करना कठिन है।

— ई-शनि

आपके द्वारा प्रदान की गई परिभाषाओं से, वे एक विवरण को छोड़कर समान दिखते हैं: और इंटरफ़ेस 100% सार है, जबकि एक सार वर्ग आंशिक रूप से सार है और कुछ विधि कार्यान्वयन हो सकता है (शायद सभी विधियों में कार्यान्वयन हो सकता है?)।

— jww

Answer 5

मैं उन अंतरों को उजागर नहीं करना चाहता, जो पहले से ही कई उत्तरों में कहा गया है (इंटरफ़ेस में चर के लिए सार्वजनिक स्थैतिक अंतिम संशोधक के बारे में, अमूर्त कक्षाओं में संरक्षित, निजी तरीकों के लिए समर्थन)

सरल शब्दों में, मैं कहना चाहूंगा:

इंटरफ़ेस: कई असंबंधित वस्तुओं द्वारा एक अनुबंध को लागू करने के लिए

अमूर्त वर्ग: कई संबंधित वस्तुओं के बीच एक ही या अलग व्यवहार को लागू करने के लिए

ओरेकल दस्तावेज से

अमूर्त कक्षाओं का उपयोग करने पर विचार करें यदि:

1. आप कई निकट संबंधित वर्गों के बीच कोड साझा करना चाहते हैं।
2. आप उम्मीद करते हैं कि आपके अमूर्त वर्ग का विस्तार करने वाले वर्गों के पास कई सामान्य तरीके या क्षेत्र हैं, या उन्हें सार्वजनिक (जैसे संरक्षित और निजी) के अलावा अन्य पहुँच संशोधक की आवश्यकता होती है।
3. आप गैर-स्थिर या गैर-अंतिम फ़ील्ड घोषित करना चाहते हैं।

यदि इंटरफेस का उपयोग करने पर विचार करें :

1. आप उम्मीद करते हैं कि असंबंधित वर्ग आपके इंटरफ़ेस को लागू करेंगे। उदाहरण के लिए, कई असंबंधित ऑब्जेक्ट Serializableइंटरफ़ेस को लागू कर सकते हैं ।
2. आप एक विशेष डेटा प्रकार के व्यवहार को निर्दिष्ट करना चाहते हैं, लेकिन इसके व्यवहार को लागू करने के बारे में चिंतित नहीं हैं।
3. आप कई प्रकार की विरासत का लाभ उठाना चाहते हैं।

अमूर्त वर्ग की स्थापना "ठोस वर्गों के साथ एक संबंध है।" इंटरफ़ेस प्रदान करता है "वर्गों के लिए एक" क्षमता है।

यदि आप Javaप्रोग्रामिंग भाषा के रूप में देख रहे हैं, तो यहां कुछ और अपडेट हैं:

जावा 8 ने एक विधि सुविधा प्रदान करके वर्गों interfaceऔर abstractवर्गों के बीच अंतर को कुछ हद तक कम कर दिया है default। एक इंटरफ़ेस में एक विधि के लिए कार्यान्वयन नहीं है जो अब मान्य नहीं है।

अधिक जानकारी के लिए इस प्रलेखन पृष्ठ का संदर्भ लें ।

बेहतर समझने के लिए कोड उदाहरणों के लिए इस एसई प्रश्न पर एक नज़र डालें।

मुझे इंटरफ़ेस और अमूर्त वर्ग के बीच अंतर कैसे समझाया जाना चाहिए?

Answer 6

कुछ महत्वपूर्ण अंतर:

तालिका के रूप में:

के रूप में जो javapapers से कहा गया है :

1. मुख्य अंतर एक जावा इंटरफेस की विधियां हैं, संक्षेप में सार हैं और कार्यान्वयन नहीं हो सकते हैं। जावा सार वर्ग में ऐसे तरीके हो सकते हैं जो एक डिफ़ॉल्ट व्यवहार को लागू करता है।

2. जावा इंटरफ़ेस में घोषित चर डिफ़ॉल्ट रूप से होता है। एक अमूर्त वर्ग में गैर-अंतिम चर हो सकते हैं।

जावा इंटरफेस के 3. डिफ़ॉल्ट रूप से सार्वजनिक होते हैं। एक जावा अमूर्त वर्ग में कक्षा के सदस्यों के सामान्य स्वाद जैसे निजी, संरक्षित, आदि हो सकते हैं।

4. जावा इंटरफेस को कीवर्ड "इम्प्लीमेंट्स" का उपयोग करके लागू किया जाना चाहिए; एक जावा अमूर्त वर्ग को कीवर्ड "एक्सटेंड्स" का उपयोग करके बढ़ाया जाना चाहिए।

5. एक इंटरफ़ेस केवल एक और जावा इंटरफ़ेस का विस्तार कर सकता है, एक अमूर्त वर्ग दूसरे जावा वर्ग का विस्तार कर सकता है और कई जावा इंटरफेस को लागू कर सकता है।

6.A जावा वर्ग कई इंटरफेस को लागू कर सकता है लेकिन यह केवल एक सार वर्ग का विस्तार कर सकता है।

7.Interface बिल्कुल सार है और इसे तुरंत नहीं किया जा सकता है; एक जावा अमूर्त वर्ग भी तात्कालिक नहीं हो सकता है, लेकिन यदि मुख्य () मौजूद है, तो इसे लागू किया जा सकता है।

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

Comments

मैंने सही उत्तर प्रदान करने के लिए आपके उत्तर को संपादित किया है। आप अपने उत्तर के नीचे एक लिंक नहीं छोड़ सकते। आपको उस भाषा को उद्धृत करना होगा जो किसी अन्य स्रोत से कॉपी की गई थी, साथ ही साथ। इसके अलावा, यदि वह तालिका कहीं से खींची गई थी, तो आपको स्पष्ट रूप से इंगित करना चाहिए कि वह कहां से है।

— ब्रैड लार्सन

कृपया C ++ के लिए भी उल्लेख करें .. हालाँकि C ++ में कोई भी कीवर्ड "इंटरफ़ेस" नहीं है, लेकिन इसका सामान्यतः पूछे जाने वाला Qn regd C ++ भी है।

— cbinder

@cbinder: c ++ में कोई कीवर्ड 'इंटरफ़ेस' नहीं है। ग में अंतर के लिए ++, देखें 1. tutorialspoint.com/cplusplus/cpp_interfaces.htm 2. tutorialspoint.com/cplusplus/cpp_interfaces.htm

— softmage99

@MageshBabu शायद शुद्ध आभासी फ़ंक्शन वाले वर्ग में एक फ़ंक्शन को परिभाषित करता है जो इसे इंटरफ़ेस के बजाय एक सार वर्ग बनाता है

— cbinder

जावा 8 के साथ, अंतर अब कम हैं। यहाँ अद्यतन अंतरों की जाँच करें: journaldev.com/1607/…

— पंकज

Answer 7

मुख्य बात यह है कि:

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

Comments

धन्यवाद अब हम एक अच्छे उच्च स्तर की प्रतिक्रिया के साथ कहीं मिल रहे हैं। मजेदार यह है कि टिप्पणियों में कितनी गहराई तक आपको एक अधिक समझ-आधारित प्रतिक्रिया खोजने के लिए जाना है।

— एंड्रयू

अन्य उत्तर भी तकनीकी हैं। यह वह है जो मुझे लगता है कि एक 'सही' उत्तर है। OOP का पूरा बिंदु शब्दार्थ है, और सीपीयू महंगे लुक्स के माध्यम से एक निजी नेस्टेड क्लास पब्लिक गेटर्स को आमंत्रित किया जाता है या नहीं, यहाँ बहुत अप्रासंगिक है

— सेंटिनल

Answer 8

जब आप वंशानुगत पदानुक्रम में बहुरूपी व्यवहार प्रदान करना चाहते हैं, तो अमूर्त कक्षाओं का उपयोग करें।

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

Answer 9

मैं 300 मंजिलों का एक भवन बना रहा हूं

इमारत का खाका इंटरफ़ेस

• उदाहरण के लिए, सर्वलेट (I)

200 मंजिलों तक निर्मित भवन - आंशिक रूप से पूर्ण --- सार

• आंशिक कार्यान्वयन, उदाहरण के लिए, सामान्य और HTTP सर्वलेट

भवन निर्माण पूरा- कंक्रीट

• पूर्ण कार्यान्वयन, उदाहरण के लिए, स्वयं सर्वलेट

इंटरफेस

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

सार

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

दुर्गाजॉब्स वेबसाइट से लिया गया

Comments

एक सार वर्ग में एक कंस्ट्रक्टर हो सकता है

— विमल कृष्ण

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

— प्रहरी

Answer 10

आइए इस प्रश्न पर फिर से काम करें:

आपको बताने वाली पहली बात यह है कि 1/1 और 1 * 1 परिणाम एक ही है, लेकिन इसका मतलब यह नहीं है कि गुणा और भाग समान है। जाहिर है, वे कुछ अच्छे संबंध रखते हैं, लेकिन आप दोनों का दिमाग अलग है।

मैं मुख्य अंतरों को इंगित करूंगा, और बाकी को पहले ही समझाया जा चुका है:

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

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

Comments

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

— एंड्रयू

"गणित रूपक बेकार है", आप ऐसा क्यों सोचते हैं?

— धनंजय

Answer 11

यह वास्तव में बहुत आसान है।

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

इसलिए एक इंटरफ़ेस केवल "घोषित" कर सकता है और उस व्यवहार को परिभाषित नहीं कर सकता है जिसे आप चाहते हैं कि कक्षा हो।

एक अमूर्त वर्ग आपको दोनों घोषित करने की अनुमति देता है (अमूर्त विधियों का उपयोग करके) साथ ही परिभाषित (पूर्ण विधि कार्यान्वयन का उपयोग करके) उस व्यवहार को करें जिसे आप वर्ग के लिए चाहते हैं।

और एक नियमित वर्ग केवल आपको परिभाषित करने की अनुमति देता है, घोषित नहीं करता है, जिस व्यवहार / क्रिया को आप वर्ग के लिए चाहते हैं।

एक अंतिम बात,

जावा में, आप कई इंटरफेस को लागू कर सकते हैं, लेकिन आप केवल एक (सार वर्ग या कक्षा) का विस्तार कर सकते हैं ...

इसका मतलब यह है कि परिभाषित व्यवहार की विरासत केवल एक प्रति वर्ग को अनुमति देने के लिए प्रतिबंधित है ... यानी यदि आप एक वर्ग चाहते थे जो कक्षा ए, बी और सी से व्यवहार समझाया गया था, तो आपको निम्न कार्य करने की आवश्यकता होगी: कक्षा ए का विस्तार बी, कक्षा सी का विस्तार ए .. इसके बारे में एक दौर की एक बिट कई विरासत है ...

दूसरी ओर इंटरफेस, आप बस कर सकते हैं: इंटरफ़ेस सी लागू करता है ए, बी

तो प्रभाव में जावा केवल "घोषित व्यवहार" यानी इंटरफेस में कई विरासत का समर्थन करता है, और परिभाषित व्यवहार के साथ केवल एक ही विरासत है .. जब तक आप मेरे द्वारा वर्णित तरीके के बारे में गोल नहीं करते हैं ...

उम्मीद है कि समझ में आता है।

Answer 12

इंटरफ़ेस बनाम अमूर्त वर्ग की तुलना गलत है। इसके बजाय दो अन्य तुलनाएँ होनी चाहिए: 1) इंटरफ़ेस बनाम वर्ग और 2) सार बनाम अंतिम वर्ग ।

इंटरफ़ेस बनाम कक्षा

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

interface Package {
  String address();
}

क्लास वस्तुओं का एक समूह है जो अनुबंध का पालन करता है। उदाहरण के लिए, मैं "बॉक्स" समूह से एक बॉक्स हूं और मैं पोस्टमैन द्वारा आवश्यक अनुबंध का पालन करता हूं। उसी समय मैं अन्य अनुबंधों का पालन करता हूं:

class Box implements Package, Property {
  @Override
  String address() {
    return "5th Street, New York, NY";
  }
  @Override
  Human owner() {
    // this method is part of another contract
  }
}

सार बनाम अंतिम

सार वर्ग अपूर्ण वस्तुओं का समूह है। उनका उपयोग नहीं किया जा सकता है, क्योंकि वे कुछ हिस्सों को याद करते हैं। उदाहरण के लिए, मैं एक अमूर्त GPS- जागरूक बॉक्स हूं - मुझे पता है कि मैं नक्शे पर अपनी स्थिति कैसे जांच सकता हूं:

abstract class GpsBox implements Package {
  @Override
  public abstract String address();
  protected Coordinates whereAmI() {
    // connect to GPS and return my current position
  }
}

यह वर्ग, यदि अन्य वर्ग द्वारा विरासत में मिला / बढ़ाया गया है, तो बहुत उपयोगी हो सकता है। लेकिन अपने आप से - यह बेकार है, क्योंकि इसमें ऑब्जेक्ट नहीं हो सकते। सार वर्ग अंतिम कक्षाओं के तत्वों का निर्माण कर सकते हैं।

अंतिम श्रेणी पूर्ण वस्तुओं का एक समूह है, जिसका उपयोग किया जा सकता है, लेकिन संशोधित नहीं किया जा सकता है। उन्हें पता है कि कैसे काम करना है और क्या करना है। जैसे, मैं एक बॉक्स हूँ जो हमेशा अपने निर्माण के दौरान निर्दिष्ट पते पर जाता है:

final class DirectBox implements Package {
  private final String to;
  public DirectBox(String addr) {
    this.to = addr;
  }
  @Override
  public String address() {
    return this.to;
  }
}

ज्यादातर भाषाओं में, जावा या सी ++ की तरह, यह सिर्फ एक वर्ग के लिए संभव है , न तो सार और न ही अंतिम। इस तरह के एक वर्ग को विरासत में दिया जा सकता है और उसे तत्काल बनाया जा सकता है। मुझे नहीं लगता कि यह वस्तु-उन्मुख प्रतिमान के अनुरूप है।

फिर से, अमूर्त वर्गों के साथ इंटरफेस की तुलना करना सही नहीं है।

Answer 13

संक्षेप में अंतर निम्नलिखित हैं:

इंटरफ़ेस और सार वर्ग के बीच सिंथेटिक अंतर :

1. विधियों और एक अमूर्त वर्ग के सदस्यों में कोई भी दृश्यता हो सकती है। एक इंटरफ़ेस के सभी तरीके सार्वजनिक होने चाहिए । // जावा 9 से अब सच नहीं है
2. एब्सट्रैक्ट क्लास के एक ठोस बच्चे को सभी अमूर्त तरीकों को परिभाषित करना चाहिए। एक सार बच्चे वर्ग सार तरीकों हो सकता है। एक अन्य इंटरफ़ेस का विस्तार करने वाले इंटरफ़ेस को मूल इंटरफ़ेस से विरासत में मिली विधियों के लिए डिफ़ॉल्ट कार्यान्वयन की आवश्यकता नहीं है।
3. एक बच्चा वर्ग केवल एक ही वर्ग का विस्तार कर सकता है। एक इंटरफ़ेस कई इंटरफेस का विस्तार कर सकता है। एक वर्ग कई इंटरफेस को लागू कर सकता है।
4. एक बच्चा वर्ग समान या कम प्रतिबंधात्मक दृश्यता के साथ अमूर्त विधियों को परिभाषित कर सकता है, जबकि एक इंटरफ़ेस को लागू करने वाले वर्ग को सभी इंटरफ़ेस विधियों को सार्वजनिक रूप से परिभाषित करना होगा।
5. एब्सट्रैक्ट क्लासेस में कंस्ट्रक्टर हो सकते हैं लेकिन इंटरफेस नहीं ।
6. जावा 9 के इंटरफेस में निजी स्थिर तरीके हैं।

अब इंटरफेस में:

public static- समर्थित
public abstract- समर्थित
public default- समर्थित
private static- समर्थित
private abstract- संकलन त्रुटि
private default- संकलन त्रुटि
private- समर्थित

Answer 14

अंतर केवल इतना है कि व्यक्ति कई उत्तराधिकार में भाग ले सकता है और अन्य नहीं।

एक इंटरफ़ेस की परिभाषा समय के साथ बदल गई है। क्या आपको लगता है कि एक इंटरफ़ेस में केवल विधि घोषणाएं हैं और सिर्फ अनुबंध हैं? स्थैतिक अंतिम चर के बारे में और जावा 8 के बाद डिफ़ॉल्ट परिभाषा के बारे में क्या?

जावा को कई विरासत के साथ हीरे की समस्या के कारण इंटरफेस शुरू किया गया था और यही वे वास्तव में करने का इरादा रखते हैं।

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

देखें कि जब वे केवल अनुबंध करने का इरादा रखते हैं तो जावा इंटरफेस में स्थिर अंतिम चर की अनुमति क्यों देता है? ।

Comments

जबकि यह एक महत्वपूर्ण अंतर है, यह एकमात्र अंतर नहीं है।

— गोविंद परमार

Answer 15

इंटरफ़ेस: बारी (बाएँ मुड़ें, दाएँ मुड़ें)।

सार वर्ग: पहिया।

क्लास: स्टीयरिंग व्हील, व्हील से निकलता है, इंटरफ़ेस टर्न को उजागर करता है

एक व्यवहार को वर्गीकृत करने के लिए है जो विभिन्न प्रकार की चीजों की पेशकश की जा सकती है, दूसरा चीजों की ऑन्कोलॉजी मॉडलिंग के लिए है।

Answer 16

यदि आपके पास कुछ सामान्य विधियां हैं जिनका उपयोग कई वर्गों द्वारा किया जा सकता है तो वे अमूर्त कक्षाओं के लिए जाते हैं। यदि आप चाहते हैं कि कक्षाएं कुछ निश्चित खाका का पालन करें तो इंटरफेस के लिए जाएं।

निम्नलिखित उदाहरण इसे प्रदर्शित करते हैं।

जावा में सार वर्ग:

abstract class animals
{
    // They all love to eat. So let's implement them for everybody
    void eat()
    {
        System.out.println("Eating...");
    }
    // The make different sounds. They will provide their own implementation.
    abstract void sound();
}

class dog extends animals
{
    void sound()
    {
        System.out.println("Woof Woof");
    }
}

class cat extends animals
{
    void sound()
    {
        System.out.println("Meoww");
    }
}

जावा में इंटरफ़ेस का कार्यान्वयन निम्नलिखित है:

interface Shape
{
    void display();
    double area();
}

class Rectangle implements Shape 
{
    int length, width;
    Rectangle(int length, int width)
    {
        this.length = length;
        this.width = width;
    }
    @Override
    public void display() 
    {
        System.out.println("****\n* *\n* *\n****"); 
    }
    @Override
    public double area() 
    {
        return (double)(length*width);
    }
} 

class Circle implements Shape 
{
    double pi = 3.14;
    int radius;
    Circle(int radius)
    {
        this.radius = radius;
    }
    @Override
    public void display() 
    {
        System.out.println("O"); // :P
    }
    @Override
    public double area() 
    { 
        return (double)((pi*radius*radius)/2);
    }
}

संक्षेप में कुछ महत्वपूर्ण मुख्य बातें:

1. जावा इंटरफ़ेस में घोषित चर डिफ़ॉल्ट अंतिम रूप से होते हैं। अमूर्त वर्गों में गैर-अंतिम चर हो सकते हैं।

2. जावा इंटरफ़ेस में घोषित चर डिफ़ॉल्ट स्थैतिक द्वारा होते हैं। सार वर्ग में गैर-स्थैतिक चर हो सकते हैं।

3. जावा इंटरफ़ेस के सदस्य डिफ़ॉल्ट रूप से सार्वजनिक होते हैं। एक जावा अमूर्त वर्ग में कक्षा के सदस्यों के सामान्य स्वाद जैसे निजी, संरक्षित, आदि हो सकते हैं।

Answer 17

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

इंटरफेस और अमूर्त वर्ग, हालांकि स्पष्ट रूप से तकनीकी दृष्टिकोण से समान है, इसके पूरी तरह से अलग अर्थ और उद्देश्य हैं।

सारांश

1. एक इंटरफेस एक अनुबंध को परिभाषित करता है कि कुछ कार्यान्वयन पूरा करेगा आप के लिए ।

2. एक अमूर्त वर्ग एक डिफ़ॉल्ट व्यवहार प्रदान करता है जिसे आपका कार्यान्वयन पुन: उपयोग कर सकता है।

वैकल्पिक सारांश

1. एक इंटरफ़ेस सार्वजनिक एपीआई को परिभाषित करने के लिए है
2. एक अमूर्त वर्ग आंतरिक उपयोग के लिए है, और एसपीआई को परिभाषित करने के लिए है

कार्यान्वयन विवरणों को छिपाने के महत्व पर

एक ठोस वर्ग वास्तविक कार्य बहुत विशिष्ट तरीके से करता है। उदाहरण के लिए, ArrayListएक कॉम्पैक्ट तरीके से वस्तुओं की एक सूची को स्टोर करने के लिए मेमोरी के एक सन्निहित क्षेत्र का उपयोग करता है जो तेजी से यादृच्छिक अभिगम, पुनरावृत्ति, और इन-प्लेस परिवर्तन प्रदान करता है, लेकिन सम्मिलन, विलोपन और कभी-कभी जोड़ भी भयानक है; इस बीच, LinkedListवस्तुओं की सूची को स्टोर करने के लिए डबल-लिंक्ड नोड्स का उपयोग करता है, जो इसके बजाय तेजी से पुनरावृत्ति, इन-प्लेस परिवर्तन और सम्मिलन / विलोपन / जोड़ प्रदान करता है, लेकिन यादृच्छिक पहुंच पर भयानक है। इन दो प्रकार की सूचियों को विभिन्न उपयोग मामलों के लिए अनुकूलित किया जाता है, और यह बहुत मायने रखता है कि आप उनका उपयोग कैसे करने जा रहे हैं। जब आप उस सूची से प्रदर्शन को निचोड़ने की कोशिश कर रहे हों, जिसके साथ आप बहुत अधिक बातचीत कर रहे हों, और जब सूची का प्रकार आप पर निर्भर हो, तो आपको सावधानीपूर्वक चुनना चाहिए कि आप किसका चयन कर रहे हैं।

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

एक अमूर्त वर्ग इंटरफेस और कंक्रीट कक्षाओं के बीच में है। यह कार्यान्वयन को सामान्य या बोरिंग कोड साझा करने में सहायता करने वाला है। उदाहरण के लिए, आकार के आधार पर AbstractCollectionमूल कार्यान्वयन प्रदान करता isEmptyहै 0, containsपुनरावृति के addAllरूप में , तुलना की जाती है, दोहराया जाता है add, और इसी तरह। यह कार्यान्वयन को उन महत्वपूर्ण भागों पर ध्यान केंद्रित करने देता है जो उनके बीच अंतर करते हैं: वास्तव में डेटा को कैसे संग्रहीत और पुनर्प्राप्त करें।

एपीआई बनाम एसपीआई

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

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

एक एपीआई और एक एसपीआई के बीच अंतर सूक्ष्म, लेकिन महत्वपूर्ण है: एक एपीआई के लिए, ध्यान केंद्रित है कि कौन इसका उपयोग करता है, और एक एसपीआई के लिए ध्यान उस पर है जो इसे लागू करता है।

एक एपीआई के तरीकों को जोड़ना आसान है, एपीआई के सभी मौजूदा उपयोगकर्ता अभी भी संकलन करेंगे। एसपीआई के तरीकों को जोड़ना कठिन है, क्योंकि प्रत्येक सेवा प्रदाता (ठोस कार्यान्वयन) को नए तरीकों को लागू करना होगा। यदि SPI को परिभाषित करने के लिए इंटरफेस का उपयोग किया जाता है, तो जब भी SPI अनुबंध बदलता है, एक प्रदाता को एक नया संस्करण जारी करना होगा। यदि इसके बजाय अमूर्त कक्षाओं का उपयोग किया जाता है, तो नए तरीकों को या तो मौजूदा सार विधियों के रूप में परिभाषित किया जा सकता है, या खाली throw not implemented exceptionस्टब्स के रूप में , जो कम से कम एक सेवा कार्यान्वयन के पुराने संस्करण को अभी भी संकलित करने और चलाने के लिए अनुमति देगा।

जावा 8 और डिफ़ॉल्ट विधियों पर एक नोट

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

कौन सा उपयोग करना है?

1. क्या इस चीज़ को सार्वजनिक रूप से कोड के अन्य भागों या अन्य बाहरी कोड द्वारा उपयोग किया जाना चाहिए ? सार्वजनिक सार अनुबंध से कार्यान्वयन विवरण को छिपाने के लिए इसमें एक इंटरफ़ेस जोड़ें, जो कि सामान्य व्यवहार है।
2. क्या ऐसी चीज़ है जिसे बहुत सारे कोड के साथ कई कार्यान्वयन के लिए माना जाता है? एक इंटरफ़ेस और एक अमूर्त, अपूर्ण कार्यान्वयन दोनों करें।
3. क्या कभी केवल एक कार्यान्वयन होने जा रहा है, और कोई भी इसका उपयोग नहीं करेगा? बस इसे एक ठोस वर्ग बनाते हैं।
   1. "कभी भी" लंबा समय होता है, आप इसे सुरक्षित खेल सकते हैं और फिर भी इसके शीर्ष पर एक इंटरफ़ेस जोड़ सकते हैं।

एक कोरोलरी: दूसरी तरह के आस-पास अक्सर गलत तरीके से किया जाता है: किसी चीज़ का उपयोग करते समय , हमेशा सबसे सामान्य वर्ग / इंटरफ़ेस का उपयोग करने की कोशिश करें जो आपको वास्तव में चाहिए। दूसरे शब्दों में, अपने चर को घोषित न करें ArrayList theList = new ArrayList(), जब तक कि आपके पास वास्तव में एक सरणी सूची होने के नाते इस पर बहुत मजबूत निर्भरता न हो, और कोई अन्य प्रकार की सूची आपके लिए इसे नहीं काटेगी। List theList = new ArrayListइसके बजाय का उपयोग करें , या भले Collection theCollection = new ArrayListही तथ्य यह है कि यह एक सूची है, और किसी भी अन्य प्रकार का संग्रह वास्तव में मायने नहीं रखता है।

Answer 18

वास्तव में मूल प्रश्न का उत्तर नहीं है, लेकिन एक बार जब आपके पास उनके बीच के अंतर का उत्तर होगा, तो आप कब-से-उपयोग-प्रत्येक दुविधा में प्रवेश करेंगे: कब इंटरफेस या अमूर्त कक्षाओं का उपयोग करें? दोनों का उपयोग कब करें?

मुझे OOP का ज्ञान सीमित है, लेकिन व्याकरण में एक विशेषण के बराबर के रूप में इंटरफेस को देखकर मेरे लिए अब तक काम किया है (मुझे सही करें अगर यह विधि फर्जी है!)। उदाहरण के लिए, इंटरफ़ेस नाम उन विशेषताओं या क्षमताओं की तरह हैं जिन्हें आप किसी कक्षा को दे सकते हैं, और एक कक्षा में उनमें से कई हो सकते हैं: ISerializable, ICountable, IList, ICacheable, IHappy, ...

Answer 19

वंशानुक्रम का उपयोग दो उद्देश्यों के लिए किया जाता है:

• किसी ऑब्जेक्ट को पेरेंट-टाइप डेटा सदस्यों और पद्धति के कार्यान्वयन के संबंध में अनुमति देने के लिए।

• एक प्रकार की वस्तुओं के संदर्भ को कोड द्वारा उपयोग किए जाने की अनुमति देने के लिए जो सुपरपेप्ट ऑब्जेक्ट के संदर्भ की अपेक्षा करता है।

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

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

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

Answer 20

प्रमुख बिंदु:

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

लाभ:

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

यहाँ विवरण प्राप्त करें ... http://pradeepatkari.wordpress.com/2014/11/20/interface-and-abstract-class-in-c-oops/

Answer 21

इसे योग करने का सबसे छोटा तरीका interfaceहै:

1. पूरी तरह से अमूर्त, अलग defaultऔर staticतरीकों से; जबकि इसके defaultऔर staticतरीकों के लिए परिभाषाएँ (विधि हस्ताक्षर + कार्यान्वयन) हैं , इसमें केवल अन्य विधियों के लिए घोषणाएँ (विधि हस्ताक्षर) हैं।
2. कक्षाओं की तुलना में लैक्सर नियमों के अधीन (एक वर्ग कई interfaceएस को लागू कर सकता है , और interfaceकई interfaceएस से विरासत में मिल सकता है )। सभी चर स्पष्ट रूप से स्थिर हैं, चाहे वे निर्दिष्ट हों public static finalया नहीं। सभी सदस्यों को स्पष्ट publicरूप से बताया गया है कि क्या इस तरह के रूप में निर्दिष्ट किया गया है या नहीं।
3. आम तौर पर एक गारंटी के रूप में उपयोग किया जाता है कि कार्यान्वयन वर्ग में निर्दिष्ट विशेषताएं होंगी और / या किसी अन्य वर्ग के साथ संगत होगी जो समान इंटरफ़ेस को लागू करता है।

इस बीच, एक abstractवर्ग है:

1. पूरी तरह से अमूर्त से कहीं भी पूरी तरह से लागू करने के लिए, एक या अधिक abstractतरीकों की प्रवृत्ति के साथ । के रूप में चिह्नित घोषणाओं के साथ घोषणा और परिभाषा दोनों हो सकते हैं abstract।
2. एक पूर्ण-वर्गीय वर्ग, और नियमों के अधीन है जो अन्य वर्गों को संचालित करते हैं (केवल एक वर्ग से विरासत में प्राप्त कर सकते हैं), इस शर्त पर कि इसे तत्काल नहीं किया जा सकता है (क्योंकि इसकी पूरी तरह से लागू होने की कोई गारंटी नहीं है)। गैर-स्थिर सदस्य चर हो सकते हैं। , सदस्य अभिगम नियंत्रण लागू कर सकते हैं के रूप में सदस्यों को प्रतिबंधित करने protected, privateया निजी पैकेज (अनिर्दिष्ट)।
3. आम तौर पर या तो कार्यान्वयन का अधिक से अधिक प्रदान करने के लिए उपयोग किया जाता है, जैसा कि कई उपवर्गों द्वारा साझा किया जा सकता है, या जैसा कि प्रोग्रामर आपूर्ति करने में सक्षम है उतना ही कार्यान्वयन प्रदान करने के लिए।

या, अगर हम इसे एक ही वाक्य में सभी को उबालना चाहते हैं: एक तो interfaceयह है कि कार्यान्वयन वर्ग के पास क्या है , लेकिन एक abstractवर्ग वह है जो उपवर्ग है ।

Answer 22

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

Answer 23

एक सरल लेकिन स्पष्ट जवाब देने के लिए, यह संदर्भ निर्धारित करने में मदद करता है: आप दोनों का उपयोग तब करते हैं जब आप पूर्ण कार्यान्वयन प्रदान नहीं करना चाहते हैं।

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

Comments

चूंकि आपने अभी इसका उत्तर दिया है, इसलिए आपका उत्तर defaultजावा 8 में कीवर्ड को ध्यान में नहीं रखता है, जिसके साथ आप इंटरफेस में ठोस तरीकों को भी परिभाषित कर सकते हैं।

— परोपकार उल्टा २ '’१19

जैसा कि मैंने कहा कि यह सीखने के स्तर पर किसी के लिए "सरल लेकिन स्पष्ट जवाब" होना चाहिए, जो कि अंतर है। उस तरह के किसी व्यक्ति के लिए, उस तरह के अपवाद के बारे में जानने का कोई फायदा नहीं है, यह केवल बहुत भ्रमित करने वाला होगा।

— user3775501

Answer 24

वास्तविक कार्यान्वयन की ओर से अमूर्त वर्ग और इंटरफ़ेस के बीच अंतर।

इंटरफ़ेस : यह एक कीवर्ड है और इसका उपयोग किसी ऑब्जेक्ट के टेम्पलेट या ब्लू प्रिंट को परिभाषित करने के लिए किया जाता है और यह सभी उप-वर्गों को एक ही प्रोटोटाइप का पालन करने के लिए मजबूर करता है, जैसा कि कार्यान्वयन के लिए है, सभी उप-वर्ग कार्यक्षमता के अनुसार कार्य करने के लिए स्वतंत्र हैं इसकी आवश्यकता है।

कुछ अन्य उपयोग के मामले जहां हमें इंटरफ़ेस का उपयोग करना चाहिए।

इंटरफेस के माध्यम से दो बाहरी वस्तुओं (हमारे आवेदन में तीसरे पक्ष के एकीकरण) के बीच संचार यहां इंटरफ़ेस अनुबंध के रूप में काम करता है।

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

सार वर्ग का उदाहरण:

 public abstract class DesireCar
  {

 //It is an abstract method that defines the prototype.
     public abstract void Color();

  // It is a default implementation of a Wheel method as all the desire cars have the same no. of wheels.   
 // and hence no need to define this in all the sub classes in this way it saves the code duplicasy     

  public void Wheel() {          

               Console.WriteLine("Car has four wheel");
                }
           }


    **Here is the sub classes:**

     public class DesireCar1 : DesireCar
        {
            public override void Color()
            {
                Console.WriteLine("This is a red color Desire car");
            }
        }

        public class DesireCar2 : DesireCar
        {
            public override void Color()
            {
                Console.WriteLine("This is a red white Desire car");
            }
        }

इंटरफ़ेस का उदाहरण:

  public interface IShape
        {
          // Defines the prototype(template) 
            void Draw();
        }


  // All the sub classes follow the same template but implementation can be different.

    public class Circle : IShape
    {
        public void Draw()
        {
            Console.WriteLine("This is a Circle");
        }
    }

    public class Rectangle : IShape
    {
        public void Draw()
        {
            Console.WriteLine("This is a Rectangle");
        }
    }

Answer 25

आप इंटरफ़ेस और अमूर्त वर्ग के बीच स्पष्ट अंतर पा सकते हैं ।

इंटरफेस

• इंटरफ़ेस में केवल सार विधियाँ हैं।
• जब उपयोगकर्ता इंटरफ़ेस लागू करता है तो सभी तरीकों को लागू करने के लिए मजबूर करें।
• केवल अंतिम और स्थिर चर शामिल हैं।
• इंटरफ़ेस कीवर्ड का उपयोग करके घोषणा करें।
• इंटरफ़ेस के सभी तरीकों को सार्वजनिक रूप से परिभाषित किया जाना चाहिए।
• एक इंटरफ़ेस विस्तार या एक वर्ग कई अन्य इंटरफेस को लागू कर सकता है।

सार वर्ग

• अमूर्त वर्ग में अमूर्त और गैर-सार तरीके शामिल हैं।

• अमूर्त वर्ग विरासत में मिलने पर सभी तरीकों को लागू करने के लिए उपयोगकर्ताओं को मजबूर नहीं करता है।

• इसमें आदिम और गैर-आदिम सहित सभी प्रकार के चर शामिल हैं

• अमूर्त कीवर्ड का उपयोग करने की घोषणा करें।

• एक सार वर्ग के तरीकों और सदस्यों को किसी भी दृश्यता के साथ परिभाषित किया जा सकता है।

• एक बच्चा वर्ग केवल एकल वर्ग (अमूर्त या ठोस) का विस्तार कर सकता है।

Answer 26

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

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

क्यों इंटरफ़ेस जब हम पहले से ही सार वर्ग है? जावा केवल बहुस्तरीय और पदानुक्रम विरासत का समर्थन करता है, लेकिन इंटरफ़ेस की सहायता से हम कई विरासत को लागू कर सकते हैं।

Answer 27

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

Answer 28

एक इंटरफ़ेस में सभी विधियों में केवल परिभाषाएँ होनी चाहिए, एक भी लागू नहीं होनी चाहिए।

लेकिन एक अमूर्त वर्ग में केवल परिभाषा के साथ एक अमूर्त विधि होनी चाहिए, लेकिन अन्य विधियां अमूर्त वर्ग में भी हो सकती हैं ...

Answer 29

हमारे पास इंटरफ़ेस और अमूर्त वर्ग के बीच विभिन्न संरचनात्मक / वाक्यात्मक अंतर हैं। कुछ और अंतर हैं

[१] परिदृश्य आधारित अंतर :

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

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

[२] वैचारिक अंतर :

"क्या हमें भविष्य में और अधिक सार तरीके प्रदान करने की आवश्यकता है" यदि हाँ इसे सार वर्ग बनाते हैं और यदि NO इसे इंटरफ़ेस बनाते हैं।

(जावा 1.7 तक सबसे उपयुक्त और मान्य)

Answer 30

आमतौर पर एब्सट्रैक्ट क्लास का इस्तेमाल किसी चीज़ की कोर के लिए किया जाता है लेकिन परिधीय को जोड़ने के लिए इस्तेमाल किया जाने वाला इंटरफ़ेस।

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

इंटरफ़ेस में अमूर्त वर्ग के बजाय अमूर्तता की विस्तृत श्रृंखला है। आप इसे पास होने वाले तर्कों में देख सकते हैं। इस उदाहरण को देखें:

यदि आप तर्क के रूप में वाहन का उपयोग करते हैं, तो आप इसके व्युत्पन्न प्रकार (बस या कार-समान श्रेणी-बस वाहन श्रेणी) का उपयोग कर सकते हैं। लेकिन जब आप तर्क के रूप में उपयोग करने योग्य इंटरफ़ेस का उपयोग करते हैं तो आपके पास अधिक विकल्प होते हैं।