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




interface abstract-class (20)

  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.

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

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

इंटरफेस:

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

सार कक्षा:

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

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

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

यह भी देखें :


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


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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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

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


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

ओरेकल website interface और abstract वर्ग के बीच महत्वपूर्ण अंतर प्रदान करती है।

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

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

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

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

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

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

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

चीजों को स्पष्ट तरीके से समझने के लिए कोड उदाहरण देखें: इंटरफ़ेस और सार कक्षा के बीच अंतर को कैसे समझाया जाना चाहिए?


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

तथा

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


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

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

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


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.


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%).

Interface Types vs. Abstract Base Classes

Adapted from the Pro C# 5.0 and the .NET 4.5 Framework book.

The interface type might seem very similar to an abstract base class. Recall that when a class is marked as abstract, it may define any number of abstract members to provide a polymorphic interface to all derived types. However, even when a class does define a set of abstract members, it is also free to define any number of constructors, field data, nonabstract members (with implementation), and so on. Interfaces, on the other hand, contain only abstract member definitions. The polymorphic interface established by an abstract parent class suffers from one major limitation in that only derived types support the members defined by the abstract parent. However, in larger software systems, it is very common to develop multiple class hierarchies that have no common parent beyond System.Object. Given that abstract members in an abstract base class apply only to derived types, we have no way to configure types in different hierarchies to support the same polymorphic interface. By way of example, assume you have defined the following abstract class:

public abstract class CloneableType
{
// Only derived types can support this
// "polymorphic interface." Classes in other
// hierarchies have no access to this abstract
// member.
   public abstract object Clone();
}

Given this definition, only members that extend CloneableType are able to support the Clone() method. If you create a new set of classes that do not extend this base class, you can't gain this polymorphic interface. Also, you might recall that C# does not support multiple inheritance for classes. Therefore, if you wanted to create a MiniVan that is-a Car and is-a CloneableType, you are unable to do so:

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

As you would guess, interface types come to the rescue. After an interface has been defined, it can be implemented by any class or structure, in any hierarchy, within any namespace or any assembly (written in any .NET programming language). As you can see, interfaces are highly polymorphic. Consider the standard .NET interface named ICloneable, defined in the System namespace. This interface defines a single method named Clone():

public interface ICloneable
{
object Clone();
}

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.


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.


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.


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.


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.


Interfaces are light weight way to enforce a particular behavior. That is one way to think of.


Though this question is quite old, I would like to add one other point in favor of interfaces:

Interfaces can be injected using any Dependency Injection tools where as Abstract class injection supported by very few.


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





abstract-class