[Oop] Interface vs classe abstraite (général OO)


Answers

Alors que votre question indique que c'est pour "OO général", il semble vraiment se concentrer sur l'utilisation .NET de ces termes.

En .NET (similaire pour Java):

  • les interfaces peuvent ne pas avoir d'état ou de mise en œuvre
  • une classe qui implémente une interface doit fournir une implémentation de toutes les méthodes de cette interface
  • les classes abstraites peuvent contenir l'état (membres de données) et / ou l'implémentation (méthodes)
  • les classes abstraites peuvent être héritées sans implémenter les méthodes abstraites (bien qu'une telle classe dérivée soit elle-même abstraite)
  • les interfaces peuvent être héritées à plusieurs, les classes abstraites ne le peuvent pas (c'est probablement la raison concrète pour laquelle les interfaces existent séparément des classes abtract - elles permettent une implémentation de l'héritage multiple qui élimine beaucoup des problèmes de MI général).

En tant que termes OO généraux, les différences ne sont pas nécessairement bien définies. Par exemple, il existe des programmeurs C ++ qui peuvent contenir des définitions rigides similaires (les interfaces sont un sous-ensemble strict de classes abstraites qui ne peuvent pas contenir d'implémentation), tandis que d'autres peuvent dire qu'une classe abstraite avec des implémentations par défaut est encore une interface ou une La classe peut encore définir une interface.

En effet, il existe un idiome C ++ appelé l'Interface Non-Virtuelle (NVI) où les méthodes publiques sont des méthodes non-virtuelles qui 'thunk' aux méthodes virtuelles privées:

Question

J'ai récemment eu deux entrevues téléphoniques au cours desquelles on m'a demandé quelles étaient les différences entre une classe Interface et une classe abstraite. J'ai expliqué tous les aspects auxquels je pouvais penser, mais il semble qu'ils attendent que je mentionne quelque chose de précis, et je ne sais pas ce que c'est.

D'après mon expérience, je pense que ce qui suit est vrai. Si un point important me manque, veuillez me le faire savoir.

Interface:

Chaque méthode déclarée dans une interface devra être implémentée dans la sous-classe. Seuls les événements, les délégués, les propriétés (C #) et les méthodes peuvent exister dans une interface. Une classe peut implémenter plusieurs interfaces.

Classe abstraite:

Seules les méthodes abstraites doivent être implémentées par la sous-classe. Une classe abstraite peut avoir des méthodes normales avec des implémentations. La classe abstraite peut également avoir des variables de classe à côté des événements, des délégués, des propriétés et des méthodes. Une classe ne peut implémenter qu'une classe abstraite uniquement en raison de l'inexistence de Multi-héritage en C #.

  1. Après tout cela, l'intervieweur a soulevé la question «Et si vous aviez un cours abstrait avec seulement des méthodes abstraites, en quoi cela serait-il différent d'une interface? Je ne connaissais pas la réponse mais je pense que c'est l'héritage comme mentionné ci-dessus, n'est-ce pas?

  2. Un autre intervieweur m'a demandé si vous aviez une variable Public à l'intérieur de l'interface, en quoi cela serait-il différent de la classe abstraite? J'ai insisté sur le fait que vous ne pouvez pas avoir de variable publique dans une interface. Je ne savais pas ce qu'il voulait entendre mais il n'était pas satisfait non plus.

Voir aussi :




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();
}



En implémentant les interfaces, vous réalisez la composition (relations "has-a") au lieu de l'héritage (relations "is-a"). C'est un principe important à retenir quand il s'agit de choses comme les modèles de conception où vous devez utiliser des interfaces pour obtenir une composition de comportements au lieu d'un héritage.




Most answers focus on the technical difference between Abstract Class and Interface, but since technically, an interface is basically a kind of abstract class (one without any data or implementation), I think the conceptual difference is far more interesting, and that might be what the interviewers are after.

An Interface is an agreement . It specifies: "this is how we're going to talk to each other". It can't have any implementation because it's not supposed to have any implementation. It's a contract. It's like the .h header files in C.

An Abstract Class is an incomplete implementation . A class may or may not implement an interface, and an abstract class doesn't have to implement it completely. An abstract class without any implementation is kind of useless, but totally legal.

Basically any class, abstract or not, is about what it is , whereas an interface is about how you use it . For example: Animal might be an abstract class implementing some basic metabolic functions, and specifying abstract methods for breathing and locomotion without giving an implementation, because it has no idea whether it should breathe through gills or lungs, and whether it flies, swims, walks or crawls. Mount , on the other hand, might be an Interface, which specifies that you can ride the animal, without knowing what kind of animal it is (or whether it's an animal at all!).

The fact that behind the scenes, an interface is basically an abstract class with only abstract methods, doesn't matter. Conceptually, they fill totally different roles.




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 dit clairement que si une classe abstraite ne contient que des déclarations de méthodes abstraites, elle devrait être déclarée comme une interface à la place.

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

Les variables dans Interfaces sont par défaut publiques statiques et finales. 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.




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.




Les intervieweurs aboient un arbre étrange. Pour les langages comme C # et Java, il y a une différence, mais dans d'autres langages comme C ++ il n'y en a pas. La théorie OO ne différencie pas les deux, mais simplement la syntaxe du langage.

Une classe abstraite est une classe avec l'implémentation et l'interface (méthodes virtuelles pures) qui seront héritées. Les interfaces n'ont généralement pas d'implémentation mais uniquement des fonctions virtuelles pures.

En C # ou Java une classe abstraite sans aucune implémentation diffère d'une interface uniquement dans la syntaxe utilisée pour en hériter et le fait que vous ne pouvez hériter que d'une seule.




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




  1. Interface:
    • 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.




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.




J'expliquerai les détails de profondeur de l'interface et la classe abstraite. Si vous connaissez l'aperçu de l'interface et de la classe abstraite, alors la première question arrivera dans votre esprit quand nous devrions utiliser Interface et quand nous devrions utiliser la classe abstraite. Donc s'il vous plaît vérifier ci-dessous l'explication de la classe Interface et abstraite.

  1. Quand devrions-nous utiliser Interface?

    si vous ne connaissez pas la mise en œuvre juste nous avons la spécification de l'exigence, alors nous allons avec Interface

  2. Quand devrions-nous utiliser la classe abstraite?

    Si vous connaissez l'implémentation mais pas complètement (implémentation partielle), alors nous allons avec la classe Abstract.

    Interface

    chaque méthode par défaut public abstrait signifie que l'interface est 100% pure abstraite.

    Abstrait

    peut avoir une méthode concrète et une méthode abstraite, ce qui est une méthode concrète, qui a une implémentation dans une classe abstraite, une classe abstraite est une classe déclarée abstraite - elle peut inclure ou non des méthodes abstraites.

    Interface

    Nous ne pouvons pas déclarer l'interface en tant que privé, protégé

    Q. Pourquoi ne déclarons-nous pas que l'interface est privée et protégée?

    Parce que par défaut, la méthode d'interface est un résumé public de telle sorte que nous ne déclarons pas l'interface comme privée et protégée.

    Méthode d'interface
    aussi nous ne pouvons pas déclarer l'interface comme privée, protégée, finale, statique, synchronisée, natif .....

    Je vais donner la raison: pourquoi nous ne déclarons pas la méthode synchronisée parce que nous ne pouvons pas créer l'objet de l'interface et synchroniser sont le travail sur l'objet et la raison pour laquelle nous ne déclarons pas la méthode synchronisée.

    Abstrait

    nous sommes heureusement utiliser avec public, privé statique final .... signifie aucune restriction sont applicables dans l'abstrait.

    Interface

    Les variables sont déclarées dans l'interface en tant que finale statique publique par défaut, donc nous ne sommes pas non plus déclarées variables en tant que private, protected.

    Le modificateur Volatile ne s'applique pas non plus dans l'interface car la variable d'interface est par défaut public statique et la variable finale vous ne pouvez pas changer la valeur une fois qu'elle affecte la variable et une fois que vous avez déclaré la variable dans l'interface.

    Et variable volatile est garder sur les changements de sorte qu'il est opp. à la finale c'est la raison pour laquelle nous n'utilisons pas de variable volatile dans l'interface.

    Abstrait

    Variable abstraite pas besoin de déclarer statique publique finale.

J'espère que cet article est utile.




Short: Les classes abstraites sont utilisées pour modéliser une hiérarchie de classe de classes similaires (par exemple Animal peut être une classe abstraite et Human, Lion, Tiger peuvent être des classes dérivées concrètes)

ET

L'interface est utilisée pour la communication entre 2 classes similaires / non similaires qui ne se soucient pas du type de l'interface implémentant la classe (par exemple, la hauteur peut être une propriété d'interface et peut être implémentée par Human, Building, Tree. , vous pouvez nager, vous pouvez mourir ou n'importe quoi .. il importe seulement une chose que vous devez avoir Hauteur (mise en œuvre dans votre classe)).




Répondez à la deuxième question: la publicvariable définie dans interfaceest static finalpar défaut tandis que la publicvariable dans la abstractclasse est une variable d'instance.




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.

Par exemple:

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

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




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

Avantages:

  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

Les inconvénients:

  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

Avantages:

  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

Les inconvénients:

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



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.




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.




Que diriez-vous d'une analogie: lorsque j'étais dans l'armée de l'air, je suis allé à l'entraînement de pilote et suis devenu un pilote de l'USAF (US Air Force). À ce moment-là, je n'étais pas qualifié pour voler quoi que ce soit et je devais suivre une formation de type avion. Une fois qualifié, j'étais pilote (classe abstraite) et pilote C-141 (cours concret). Lors d'une de mes missions, on m'a confié un devoir supplémentaire: officier de sécurité. Maintenant, j'étais encore pilote et pilote de C-141, mais j'ai également effectué des tâches d'agent de sécurité (j'ai mis en place ISafetyOfficer, pour ainsi dire). Un pilote n'était pas tenu d'être un agent de sécurité, d'autres auraient pu le faire aussi.

Tous les pilotes de l'USAF doivent suivre certaines règles de l'Air Force, et tous les pilotes C-141 (ou F-16, ou T-38) sont des pilotes de l'USAF. N'importe qui peut être un agent de sécurité. Donc, pour résumer:

  • Pilote: classe abstraite
  • C-141 Pilot: classe concrète
  • ISafety Officer: interface

note ajoutée: ceci était censé être une analogie pour aider à expliquer le concept, pas une recommandation de codage. Voir les différents commentaires ci-dessous, la discussion est intéressante.




Héritage
Considérons une voiture et un bus. Ce sont deux véhicules différents. Mais encore, ils partagent quelques propriétés communes comme ils ont une direction, des freins, des engrenages, un moteur etc.
Donc, avec le concept d'héritage, cela peut être représenté comme suit ...

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 ...
}

Maintenant un vélo ...

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

Et une voiture ...

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

C'est tout à propos de l' héritage . Nous les utilisons pour classer les objets dans des formes de base plus simples et leurs enfants comme nous l'avons vu ci-dessus.

Classes abstraites

Les classes abstraites sont des objets incomplets . Pour mieux comprendre, considérons l'analogie du véhicule une fois de plus.
Un véhicule peut être conduit. Droite? Mais différents véhicules sont conduits de différentes façons ... Par exemple, vous ne pouvez pas conduire une voiture comme vous conduisez un vélo.
Alors, comment représenter la fonction de conduite d'un véhicule? Il est plus difficile de vérifier quel type de véhicule il est et de le piloter avec sa propre fonction; vous devriez changer la classe de conducteur encore et encore en ajoutant un nouveau type de véhicule.
Voici le rôle des classes et des méthodes abstraites. Vous pouvez définir la méthode de lecteur comme abstraite pour indiquer que tous les enfants héritiers doivent implémenter cette fonction.
Donc, si vous modifiez la classe de véhicule ...

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

Le vélo et la voiture doivent également spécifier comment le conduire. Sinon, le code ne sera pas compilé et une erreur est générée.
En bref .. une classe abstraite est une classe partiellement incomplète avec des fonctions incomplètes, que les enfants héritiers doivent spécifier les leurs.

Interfaces Les interfaces sont totalement incomplètes. Ils n'ont pas de propriétés. Ils indiquent simplement que les enfants héritiers sont capables de faire quelque chose ...
Supposons que vous avez différents types de téléphones mobiles avec vous. Chacun d'eux a différentes façons de faire différentes fonctions; Ex: appeler une personne. Le fabricant du téléphone spécifie comment le faire. Ici, les téléphones mobiles peuvent composer un numéro - c'est-à-dire, il est dial-able. Représenter ceci comme une interface.

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

Ici, le fabricant du Dialable définit comment composer un numéro. Vous avez juste besoin de lui donner un numéro à composer.

// 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);
}
.....

En utilisant ici des interfaces au lieu de classes abstraites, l'auteur de la fonction qui utilise un Dialable n'a pas besoin de s'inquiéter de ses propriétés. Ex: A-t-il un écran tactile ou un clavier, Est-ce un téléphone fixe fixe ou un téléphone mobile. Vous avez juste besoin de savoir s'il est possible de le numéroter. hérite-t-il (ou implémente-t-il) l'interface Dialable?

Et plus important encore , si un jour vous changez le Dialable avec un autre

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

Vous pouvez être sûr que le code fonctionne toujours parfaitement car la fonction qui utilise le composant ne dépend pas (et ne peut pas) des détails autres que ceux spécifiés dans l'interface Dialable. Ils implémentent tous deux une interface Dialable et c'est la seule chose sur laquelle la fonction se soucie.

Les interfaces sont couramment utilisées par les développeurs pour assurer l'interopérabilité (utilisation interchangeable) entre objets, dans la mesure où ils partagent une fonction commune (tout comme vous pouvez passer à un téléphone fixe ou mobile, dans la mesure où vous avez juste besoin de composer un numéro). En bref, les interfaces sont une version beaucoup plus simple des classes abstraites, sans aucune propriété.
Notez également que vous pouvez implémenter (hériter) autant d'interfaces que vous le souhaitez, mais vous ne pouvez étendre (hériter) qu'une seule classe parente.

Plus d'informations Classes abstraites vs interfaces




Je pense qu'ils n'ont pas aimé votre réponse parce que vous avez donné les différences techniques au lieu des différences de conception. La question est comme une question de troll pour moi. En fait, les interfaces et les classes abstraites ont une nature complètement différente, donc vous ne pouvez pas vraiment les comparer. Je vais vous donner ma vision de ce qu'est le rôle d'une interface et quel est le rôle d'une classe abstraite.

interface: permet d'assurer un contrat et de faire un couplage faible entre les classes afin d'avoir une application plus maintenable, évolutive et testable.

Classe abstraite: sert uniquement à factoriser du code entre des classes de même responsabilité. Notez que c'est la principale raison pour laquelle l'héritage multiple est une mauvaise chose dans la POO, car une classe ne devrait pas gérer beaucoup de responsabilités (utiliser la composition place).

Les interfaces ont donc un véritable rôle architectural alors que les classes abstraites ne sont quasiment qu'un détail de mise en œuvre (si vous l'utilisez correctement bien sûr).




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.




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.

Interface:

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.

Exemple:

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" .

Addenda

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

Classe:

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.




Pour .Net,

Votre réponse à The second interviewer est aussi la réponse à la première ... Les classes abstraites peuvent avoir une implémentation, ET état, les interfaces ne peuvent pas ...

EDIT: Sur une autre note, je n'utiliserais même pas l'expression 'subclass' (ou la phrase 'inheritance') pour décrire les classes qui sont 'définies pour implémenter' une interface. Pour moi, une interface est une définition d'un contrat auquel une classe doit se conformer si elle a été définie pour «implémenter» cette interface. Il n'hérite de rien ... Vous devez tout ajouter vous-même, explicitement.




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.




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



Je pense que la réponse qu'ils recherchent est la différence philosophique fondamentale ou OPPS.

L'héritage de classe abstraite est utilisé lorsque la classe dérivée partage les propriétés de base et le comportement de la classe abstraite. Le type de comportement qui définit réellement la classe.

D'autre part, l'héritage de l'interface est utilisé lorsque les classes partagent un comportement périphérique, celles qui ne définissent pas nécessairement la classe dérivée.

Par exemple. Une voiture et un camion partagent beaucoup de propriétés de base et de comportement d'une classe abstraite automobile, mais ils partagent aussi un comportement périphérique comme Générer des gaz d'échappement que même des classes non automobiles comme Drillers ou PowerGenerators partagent et ne définit pas nécessairement une voiture ou un camion , Car, Truck, Driller et PowerGenerator peuvent tous partager la même interface IExhaust.




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.




D'un point de vue conceptuel, maintenir la mise en œuvre, les règles, les avantages et la réalisation de tout objectif de programmation en utilisant quelqu'un ou les deux, peut ou ne peut pas avoir de code / données / propriété, bla bla, héritage simple ou multiple,

1- La classe abstraite (ou purement abstraite) est destinée à implémenter la hiérarchie. Si vos objets métier ont une structure similaire, représentant une sorte de relation parent-enfant (hiérarchie), seuls les classes d'héritage / abstrait seront utilisées. Si votre modèle d'entreprise n'a pas de hiérarchie, l'héritage ne doit pas être utilisé (ici, je ne parle pas de logique de programmation, par exemple certains modèles de conception nécessitent un héritage). Conceptuellement, la classe abstraite est une méthode pour implémenter la hiérarchie d'un modèle d'affaires dans OOP, elle n'a rien à voir avec Interfaces, en comparant la classe abstraite avec l'interface est sans signification parce que les deux sont des choses conceptuellement totalement différentes, il est demandé les concepts car ils ont l'air d'offrir à la fois les mêmes fonctionnalités lors de la mise en œuvre et les programmeurs mettent généralement l'accent sur le codage. [Gardez cela à l'esprit que l'abstraction est différente de la classe abstraite].

2- Une interface est un contrat, une fonctionnalité commerciale complète représentée par un ou plusieurs ensembles de fonctions. C'est pourquoi il est implémenté et non hérité. Un objet métier (partie d'une hiérarchie ou non) peut avoir un nombre illimité de fonctionnalités métier complètes. Cela n'a rien à voir avec les classes abstraites, c'est-à-dire l'héritage en général. Par exemple, un humain peut exécuter, un éléphant peut exécuter, un oiseau peut exécuter, et ainsi de suite, tous ces objets de hiérarchie différente implémenteraient l'interface RUN ou l'interface EAT ou SPEAK. N'entrez pas dans l'implémentation car vous pourriez l'implémenter en ayant des classes abstraites pour chaque type implémentant ces interfaces. Un objet de n'importe quelle hiérarchie peut avoir une fonctionnalité (interface) qui n'a rien à voir avec sa hiérarchie.

Je crois que les interfaces n'ont pas été inventées pour réaliser des héritages multiples ou pour exposer le comportement public, et de même, les classes abstraites ne doivent pas remplacer les interfaces, mais Interface est une fonctionnalité qu'un objet peut faire (via les fonctions de cette interface). parent d'une hiérarchie pour produire des enfants ayant la structure de base (propriété + fonctionnalité) du parent

Lorsque vous êtes interrogé sur la différence, il s'agit en fait de la différence conceptuelle et non de la différence dans la mise en œuvre spécifique à une langue, à moins d'une demande explicite.

Je crois que les deux intervieweurs s'attendaient à une différence directe entre les deux et quand vous avez échoué, ils ont essayé de vous conduire vers cette différence en mettant en œuvre ONE comme l'AUTRE.

Et si vous aviez une classe abstraite avec seulement des méthodes abstraites?




Il y a quelques autres différences -

Les interfaces ne peuvent avoir aucune implémentation concrète. Les classes de base abstraites peuvent. Cela vous permet de fournir des implémentations concrètes là-bas. Cela peut permettre à une classe de base abstraite de fournir un contrat plus rigoureux, alors qu'une interface ne décrit réellement que l'utilisation d'une classe. (La classe de base abstraite peut avoir des membres non-virtuels définissant le comportement, ce qui donne plus de contrôle à l'auteur de la classe de base.)

Plus d'une interface peut être implémentée sur une classe. Une classe ne peut dériver que d'une seule classe de base abstraite. Cela permet une hiérarchie polymorphe à l'aide d'interfaces, mais pas de classes de base abstraites. Cela permet également un pseudo-multi-héritage en utilisant des interfaces.

Les classes de base abstraites peuvent être modifiées dans v2 + sans casser l'API. Les modifications apportées aux interfaces perturbent les changements.

[C # /. NET Specific] Les interfaces, contrairement aux classes de base abstraites, peuvent être appliquées aux types de valeur (structures). Les structures ne peuvent pas hériter des classes de base abstraites. Cela permet d'appliquer des contrats comportementaux / des directives d'utilisation sur les types de valeur.




Si vous considérez java comme un langage OOP pour répondre à cette question, la version Java 8 rend obsolète une partie du contenu des réponses ci-dessus. Maintenant, l'interface java peut avoir des méthodes par défaut avec une implémentation concrète.

Le website Oracle fournit des différences clés entre l' interface et abstract classe abstract .

Envisagez d'utiliser des classes abstraites si:

  1. Vous souhaitez partager du code entre plusieurs classes étroitement liées.
  2. Vous vous attendez à ce que les classes qui étendent votre classe abstraite aient plusieurs méthodes ou champs communs, ou nécessitent des modificateurs d'accès autres que publics (tels que protected et private).
  3. Vous voulez déclarer des champs non statiques ou non finaux.

Envisagez d'utiliser des interfaces si:

  1. Vous vous attendez à ce que des classes indépendantes implémenter votre interface. Par exemple, de nombreux objets indépendants peuvent implémenter l'interface Serializable .
  2. Vous souhaitez spécifier le comportement d'un type de données particulier, mais ne vous inquiétez pas de savoir qui implémente son comportement.
  3. Vous voulez profiter de l'héritage multiple de type.

En termes simples, je voudrais utiliser

interface: pour implémenter un contrat avec plusieurs objets indépendants

Classe abstraite: Pour implémenter le même comportement ou un comportement différent parmi plusieurs objets associés

Jetez un oeil à l'exemple de code pour comprendre les choses de manière claire: Comment aurais-je expliqué la différence entre une interface et une classe abstraite?