oop इंटरफेस बनाम सार कक्षा(सामान्य ओओ)




interface abstract-class (24)

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

मेरे अनुभव से मुझे लगता है कि निम्नलिखित सत्य है। अगर मुझे एक प्रमुख बिंदु याद आ रहा है तो कृपया मुझे बताएं।

इंटरफेस:

एक इंटरफेस में घोषित हर एक विधि उपclass में लागू किया जाना होगा। इंटरफेस में केवल घटनाक्रम, प्रतिनिधि, गुण (सी #) और तरीके मौजूद हो सकते हैं। एक वर्ग कई इंटरफेस लागू कर सकते हैं।

सार कक्षा:

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

  1. आखिरकार, साक्षात्कारकर्ता सवाल के साथ आया "क्या होगा यदि आपके पास केवल सार तत्वों के साथ सार तत्व था? यह एक इंटरफ़ेस से अलग कैसे होगा?" मुझे जवाब नहीं पता था, लेकिन मुझे लगता है कि यह उपरोक्त वर्णित विरासत है?

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

यह भी देखें :


Difference between Java Interface and Abstract Class

  1. Main difference is methods of a Java interface are implicitly abstract and cannot have implementations. A Java abstract class can have instance methods that implements a default behavior.

  2. Variables declared in a Java interface is by default final. An abstract class may contain non-final variables.

  3. Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private, protected, etc..

  4. Java interface should be implemented using keyword “implements”; A Java abstract class should be extended using keyword “extends”.

  5. An interface can extend another Java interface only, an abstract class can extend another Java class and implement multiple Java interfaces.

  6. A Java class can implement multiple interfaces but it can extend only one abstract class.

  7. Interface is absolutely abstract and cannot be instantiated; A Java abstract class also cannot be instantiated, but can be invoked if a main() exists.

  8. In comparison with java abstract classes, java interfaces are slow as it requires extra indirection.


After all that, the interviewer came up with the question "What if you had an 
Abstract class with only abstract methods? How would that be different
from an interface?" 

docs.oracle.com/javase/tutorial/java/IandI/abstract.html स्पष्ट रूप से कहता है कि यदि एक अमूर्त वर्ग में केवल अमूर्त विधि घोषणाएं होती हैं, तो इसे इसके बजाय एक इंटरफेस के रूप में घोषित किया जाना चाहिए।

An another interviewer asked me what if you had a Public variable inside
the interface, how would that be different than in Abstract Class?

Variables in Interfaces are by default public static and final. Question could be framed like what if all variables in abstract class are public? Well they can still be non static and non final unlike the variables in interfaces.

Finally I would add one more point to those mentioned above - abstract classes are still classes and fall in a single inheritance tree whereas interfaces can be present in multiple inheritance.


From another answer of mine , mostly dealing with when to use one versus the other:

In my experience, interfaces are best used when you have several classes which each need to respond to the same method or methods so that they can be used interchangeably by other code which will be written against those classes' common interface. The best use of an interface is when the protocol is important but the underlying logic may be different for each class. If you would otherwise be duplicating logic, consider abstract classes or standard class inheritance instead.


नेट के लिए,

दूसरे साक्षात्कारकर्ता का आपका जवाब भी पहले का जवाब है ... सार कक्षाओं में कार्यान्वयन हो सकता है, और राज्य, इंटरफेस नहीं कर सकते ...

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


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

सभी यूएसएएफ पायलटों को कुछ वायु सेना के व्यापक नियमों का पालन करना होगा, और सभी सी -141 (या एफ -16, या टी -38) पायलट 'यूएसएएफ पायलट' हैं। कोई भी सुरक्षा अधिकारी हो सकता है। तो, संक्षेप में:

  • पायलट: अमूर्त वर्ग
  • सी -141 पायलट: ठोस वर्ग
  • ISafety अधिकारी: इंटरफ़ेस

जोड़ा गया नोट: यह अवधारणा को समझाने में मदद करने के लिए एक समानता होना था, कोडिंग अनुशंसा नहीं। नीचे दी गई विभिन्न टिप्पणियां देखें, चर्चा दिलचस्प है।


1) An interface can be seen as a pure Abstract Class, is the same, but despite this, is not the same to implement an interface and inheriting from an abstract class. When you inherit from this pure abstract class you are defining a hierarchy -> inheritance, if you implement the interface you are not, and you can implement as many interfaces as you want, but you can only inherit from one class.

2) You can define a property in an interface, so the class that implements that interface must have that property.

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

  public interface IVariable
  {
      string name {get; set;}
  }

The class that implements that interface must have a property like that.


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


Couple of other differences:

Abstract classes can have static methods, properties, fields etc. and operators, interfaces can't. Cast operator allows casting to/from abstract class but don't allow casting to/from interface.

So pretty much you can use abstract class on its own even if it is never implemented (through its static members) and you can't use interface on its own in any way.


For sure it is important to understand the behavior of interface and abstract class in OOP (and how languages handle them), but I think it is also important to understand what exactly each term means. Can you imagine the if command not working exactly as the meaning of the term? Also, actually some languages are reducing, even more, the differences between an interface and an abstract... if by chance one day the two terms operate almost identically, at least you can define yourself where (and why) should any of them be used for.

If you read through some dictionaries and other fonts you may find different meanings for the same term but having some common definitions. I think these two meanings I found in this site are really, really good and suitable.

इंटरफेस:

A thing or circumstance that enables separate and sometimes incompatible elements to coordinate effectively.

Abstract:

Something that concentrates in itself the essential qualities of anything more extensive or more general, or of several things; essence.

उदाहरण:

You bought a car and it needs fuel.

Your car model is XYZ , which is of genre ABC , so it is a concrete car, a specific instance of a car. A car is not a real object. In fact, it is an abstract set of standards (qualities) to create a specific object. In short, Car is an abstract class , it is "something that concentrates in itself the essential qualities of anything more extensive or more general" .

The only fuel that matches the car manual specification should be used to fill up the car tank. In reality, there is nothing to restrict you to put any fuel but the engine will work properly only with the specified fuel, so it is better to follow its requirements. The requirements say that it accepts, as other cars of the same genre ABC , a standard set of fuel.

In an Object Oriented view, fuel for genre ABC should not be declared as a class because there is no concrete fuel for a specific genre of car out there. Although your car could accept an abstract class Fuel or VehicularFuel, you must remember that your only some of the existing vehicular fuel meet the specification, those that implement the requirements in your car manual. In short, they should implement the interface ABCGenreFuel , which "... enables separate and sometimes incompatible elements to coordinate effectively" .

परिशिष्ट

In addition, I think you should keep in mind the meaning of the term class, which is (from the same site previously mentioned):

Class:

A number of persons or things regarded as forming a group by reason of common attributes, characteristics, qualities, or traits; kind;

This way, a class (or abstract class) should not represent only common attributes (like an interface), but some kind of group with common attributes. An interface doesn't need to represent a kind. It must represent common attributes. This way, I think classes and abstract classes may be used to represent things that should not change its aspects often, like a human being a Mammal, because it represents some kinds. Kinds should not change themselves that often.


दूसरा सवाल का उत्तर: publicचर में परिभाषित किया गया interfaceहै static finalडिफ़ॉल्ट रूप से, जबकि publicमें चर abstractवर्ग एक उदाहरण चर रहा है।


मुझे लगता है कि वे जो जवाब खोज रहे हैं वह मौलिक या ओपीपीएस दार्शनिक अंतर है।

अमूर्त वर्ग विरासत का उपयोग तब किया जाता है जब व्युत्पन्न वर्ग कोर गुणों और सार वर्ग के व्यवहार को साझा करता है। वास्तव में कक्षा को परिभाषित करने वाला व्यवहार।

दूसरी ओर इंटरफ़ेस विरासत का उपयोग तब किया जाता है जब कक्षा परिधीय व्यवहार साझा करती है, जो आवश्यक रूप से व्युत्पन्न कक्षा को परिभाषित नहीं करते हैं।

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


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

public class Vehicle {
    private Driver driver;
    private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections).
    //You can define as many properties as you want here ...
}

अब एक साइकिल ...

public class Bicycle extends Vehicle {
    //You define properties which are unique to bicycles here ...
    private Pedal pedal;
}

और एक कार ...

public class Car extends Vehicle {
    private Engine engine;
    private Door[] doors;
}

यह विरासत के बारे में सब कुछ है। हम उन वस्तुओं को वर्गीकृत करने के लिए सरल आधार रूपों और उनके बच्चों को वर्गीकृत करने के लिए उपयोग करते हैं जैसा हमने ऊपर देखा था।

सार कक्षाएं

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

//......Code of Vehicle Class
abstract public void drive();
//.....Code continues

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

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

public interface Dialable {
    public void dial(Number n);
}

यहां डायल करने योग्य निर्माता परिभाषित करता है कि किसी संख्या को डायल करने के तरीके को कैसे परिभाषित किया जाता है। आपको इसे डायल करने के लिए केवल एक नंबर देने की आवश्यकता है।

// Makers define how exactly dialable work inside.

Dialable PHONE1 = new Dialable() {
    public void dial(Number n) {
        //Do the phone1's own way to dial a number
    }
}

Dialable PHONE2 = new Dialable() {
    public void dial(Number n) {
        //Do the phone2's own way to dial a number
    }
}


//Suppose there is a function written by someone else, which expects a Dialable
......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE1;
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

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

और सबसे महत्वपूर्ण बात यह है कि अगर किसी दिन आप डायलबल को एक अलग से स्विच करते हैं

......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

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

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

अधिक जानकारी सार वर्ग बनाम इंटरफेस


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

  1. जब हमें इंटरफेस का उपयोग करना चाहिए?

    यदि आप कार्यान्वयन के बारे में नहीं जानते हैं तो हमारे पास आवश्यकता विनिर्देश है तो हम इंटरफ़ेस के साथ जाते हैं

  2. जब हमें सार कक्षा का उपयोग करना चाहिए?

    यदि आप कार्यान्वयन जानते हैं लेकिन पूरी तरह से (आंशिक रूप से कार्यान्वयन नहीं) तो हम सार कक्षा के साथ जाते हैं।

    इंटरफेस

    डिफ़ॉल्ट सार्वजनिक सार द्वारा प्रत्येक विधि का अर्थ इंटरफ़ेस 100% शुद्ध सार है।

    सार

    कंक्रीट विधि और सार विधि हो सकती है, कंक्रीट विधि क्या है, जिसमें सार वर्ग में कार्यान्वयन होता है, एक सार वर्ग एक वर्ग है जिसे सार घोषित किया जाता है-इसमें अमूर्त विधियां शामिल हो सकती हैं या नहीं भी हो सकती हैं।

    इंटरफेस

    हम एक निजी, संरक्षित के रूप में इंटरफेस घोषित नहीं कर सकते हैं

    प्र। हम इंटरफेस को निजी और संरक्षित क्यों नहीं घोषित कर रहे हैं?

    क्योंकि डिफ़ॉल्ट इंटरफ़ेस विधि द्वारा सार्वजनिक सार है इसलिए और इसलिए कि हम इंटरफ़ेस को निजी और संरक्षित घोषित नहीं कर रहे हैं।

    इंटरफ़ेस विधि
    हम भी इंटरफ़ेस को निजी, संरक्षित, अंतिम, स्थैतिक, सिंक्रनाइज़, मूल के रूप में घोषित नहीं कर सकते .....

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

    सार

    हम सार्वजनिक रूप से सार्वजनिक, निजी अंतिम स्थिर के साथ खुशी से उपयोग कर रहे हैं .... मतलब है कि सार में कोई प्रतिबंध लागू नहीं है।

    इंटरफेस

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

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

    और अस्थिर चर बदलता रहता है, इसलिए यह opp है। अंतिम कारण यह है कि हम इंटरफ़ेस में अस्थिर चर का उपयोग नहीं कर रहे हैं।

    सार

    सार परिवर्तनीय सार्वजनिक स्थिर फाइनल घोषित करने की कोई ज़रूरत नहीं है।

मुझे उम्मीद है कि यह लेख उपयोगी है।


जबकि आपका प्रश्न इंगित करता है कि यह "सामान्य ओओ" के लिए है, यह वास्तव में इन शर्तों के .NET उपयोग पर ध्यान केंद्रित कर रहा है।

.NET में (जावा के लिए समान):

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

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

वास्तव में, गैर-वर्चुअल इंटरफेस (एनवीआई) नामक एक सी ++ मुहावरे है जहां सार्वजनिक विधियां गैर वर्चुअल विधियां हैं जो निजी वर्चुअल विधियों के लिए 'थंक' होती हैं:


लघु: सार वर्गों का उपयोग समान दिखने वाले वर्गों के वर्ग पदानुक्रम को मॉडलिंग के लिए किया जाता है (उदाहरण के लिए पशु अमूर्त वर्ग और मानव हो सकता है, शेर, बाघ कंक्रीट व्युत्पन्न कक्षाएं हो सकता है)

तथा

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


An interface defines a contract for a service or set of services. They provide polymorphism in a horizontal manner in that two completely unrelated classes can implement the same interface but be used interchangeably as a parameter of the type of interface they implement, as both classes have promised to satisfy the set of services defined by the interface. Interfaces provide no implementation details.

An abstract class defines a base structure for its sublcasses, and optionally partial implementation. Abstract classes provide polymorphism in a vertical, but directional manner, in that any class that inherits the abstract class can be treated as an instance of that abstract class but not the other way around. Abstract classes can and often do contain implementation details, but cannot be instantiated on their own- only their subclasses can be "newed up".

C# does allow for interface inheritance as well, mind you.


Interface : should be used if you want to imply a rule on the components which may or may not be related to each other

Pros:

  1. Allows multiple inheritance
  2. Provides abstraction by not exposing what exact kind of object is being used in the context
  3. provides consistency by a specific signature of the contractInterface:
  4. Allows multiple inheritance
  5. Provides abstraction by not exposing what exact kind of object is being used in the context
  6. Provides consistency by a specific signature of the contract

Cons:

  1. Must implement all the contracts defined
  2. Cannot have variables or delegates
  3. Once defined cannot be changed without breaking all the classes

Abstract Class : should be used where you want to have some basic or default behaviour or implementation for components related to each other

Pros:

  1. Faster then interface
  2. Has flexibility in the implementation (you can implement it fully or partially)
  3. Can be easily changed without breaking the derived classes

Cons:

  1. Cannot be instantiated
  2. Does not support multiple inheritance

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

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

अमूर्त वर्ग: केवल उसी उत्तरदायित्व के वर्गों के बीच कुछ कोड को कारक बनाने के लिए उपयोग किया जाता है। ध्यान दें कि ओओपी में एकाधिक विरासत एक बुरी चीज क्यों है, क्योंकि एक वर्ग को कई जिम्मेदारियों को संभालना नहीं चाहिए (इसके बजाय composition उपयोग करें)।

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


Abstract class And Interface Difference :

  1. Abstract class can have abstract and non-abstract methods and Interface can have only abstract methods.
  2. Abstract class doesn't support multiple inheritance And Interface supports multiple inheritance.
  3. Abstract class can have final, non-final, static and non-static variables And Interface has only static and final variables.
  4. Abstract class can have static methods, main method and constructor And Interface can't have static methods, main method or constructor.
  5. Abstract class can provide the implementation of interface And Interface can't provide the implementation of abstract class.
  6. The abstract keyword is used to declare abstract class And The interface keyword is used to declare interface.
  7. Abstract class achieves partial abstraction (0 to 100%) because there are non abstract methods also in abstract class whereas interface achieves fully abstraction (100%).

Copied from CLR via C# by Jeffrey Richter...

I often hear the question, “Should I design a base type or an interface?” The answer isn't always clearcut.

Here are some guidelines that might help you:

■■ IS-A vs. CAN-DO relationship A type can inherit only one implementation. If the derived type can't claim an IS-A relationship with the base type, don't use a base type; use an interface. Interfaces imply a CAN-DO relationship. If the CAN-DO functionality appears to belong with various object types, use an interface. For example, a type can convert instances of itself to another type (IConvertible), a type can serialize an instance of itself (ISerializable), etc. Note that value types must be derived from System.ValueType, and therefore, they cannot be derived from an arbitrary base class. In this case, you must use a CAN-DO relationship and define an interface.

■■ Ease of use It's generally easier for you as a developer to define a new type derived from a base type than to implement all of the methods of an interface. The base type can provide a lot of functionality, so the derived type probably needs only relatively small modifications to its behavior. If you supply an interface, the new type must implement all of the members.

■■ Consistent implementation No matter how well an interface contract is documented, it's very unlikely that everyone will implement the contract 100 percent correctly. In fact, COM suffers from this very problem, which is why some COM objects work correctly only with Microsoft Word or with Windows Internet Explorer. By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.

■■ Versioning If you add a method to the base type, the derived type inherits the new method, you start off using a type that works, and the user's source code doesn't even have to be recompiled. Adding a new member to an interface forces the inheritor of the interface to change its source code and recompile.


  1. इंटरफेस:
    • We do not implement (or define) methods, we do that in derived classes.
    • We do not declare member variables in interfaces.
    • Interfaces express the HAS-A relationship. That means they are a mask of objects.
  2. Abstract class:
    • We can declare and define methods in abstract class.
    • We hide constructors of it. That means there is no object created from it directly.
    • Abstract class can hold member variables.
    • Derived classes inherit to abstract class that mean objects from derived classes are not masked, it inherit to abstract class. The relationship in this case is IS-A.

This is my opinion.


As you might have got the theoretical knowledge from the experts, I am not spending much words in repeating all those here, rather let me explain with a simple example where we can use/cannot use Interface and Abstract class .

Consider you are designing an application to list all the features of Cars. In various points you need inheritance in common, as some of the properties like DigitalFuelMeter, Air Conditioning, Seat adjustment, etc are common for all the cars. Likewise, we need inheritance for some classes only as some of the properties like the Braking system (ABS,EBD) are applicable only for some cars.

The below class acts as a base class for all the cars:

public class Cars
{
    public string DigitalFuelMeter()
    {
        return "I have DigitalFuelMeter";
    }

    public string AirCondition()
    {
        return "I have AC";
    }

    public string SeatAdjust()
    {
        return "I can Adjust seat";
    }
}

Consider we have a separate class for each Cars.

public class Alto : Cars
{
    // Have all the features of Car class    
}

public class Verna : Cars
{
    // Have all the features of Car class + Car need to inherit ABS as the Braking technology feature which is not in Cars        
}

public class Cruze : Cars
{
    // Have all the features of Car class + Car need to inherit EBD as the Braking technology feature which is not in Cars        
}

Consider we need a method for inheriting the Braking technology for the cars Verna and Cruze (not applicable for Alto). Though both uses braking technology, the "technology" is different. So we are creating an abstract class in which the method will be declared as Abstract and it should be implemented in its child classes.

public abstract class Brake
{
    public abstract string GetBrakeTechnology();
}

Now we are trying to inherit from this abstract class and the type of braking system is implemented in Verna and Cruze:

public class Verna : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }       
}

public class Cruze : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
       return "I use EBD system for braking";
    }         
}

See the problem in the above two classes? They inherit from multiple classes which C#.Net doesn't allow even though the method is implemented in the children. Here it comes the need of Interface.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

And the implementation is given below:

public class Verna : Cars, IBrakeTechnology
{
    public string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }
}

public class Cruze : Cars, IBrakeTechnology
{
   public string GetBrakeTechnology()
   {
       return "I use EBD system for braking";
   }        
}

Now Verna and Cruze can achieve multiple inheritance with its own kind of braking technologies with the help of Interface.


कुछ अन्य मतभेद हैं -

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

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

एपीआई तोड़ने के बिना v2 + में सार बेस कक्षाओं को संशोधित किया जा सकता है। इंटरफेस में परिवर्तन परिवर्तन तोड़ रहे हैं।

[सी # / .NET विशिष्ट] इंटरफेस, सार आधार वर्गों के विपरीत, मूल्य प्रकारों (structs) पर लागू किया जा सकता है। स्ट्रक्चर अमूर्त आधार वर्गों से प्राप्त नहीं हो सकते हैं। यह वैल्यू प्रकारों पर व्यवहारिक अनुबंध / उपयोग दिशानिर्देशों को लागू करने की अनुमति देता है।


साक्षात्कारकर्ता एक विषम पेड़ को भड़क रहे हैं। सी # और जावा जैसी भाषाओं के लिए, एक अंतर है, लेकिन सी ++ जैसी अन्य भाषाओं में ऐसा नहीं है। ओओ सिद्धांत दोनों को अलग नहीं करता है, केवल भाषा का वाक्यविन्यास।

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

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





abstract-class