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



14 Answers

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.

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 :




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.




  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.




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




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.




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



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.




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.




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?




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.




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.




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




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



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?




Related