Les principales différences techniques entre une classe abstraite et une interface sont:

• Les classes abstraites peuvent avoir constantes, membres, stubs de méthode (méthodes sans corps) et méthodes définies, alors que les interfaces ne peuvent avoir que constanteset stubs de méthodes.

• Les méthodes et les membres d'une classe abstraite peuvent être définis avec any visibility, alors que toutes les méthodes d'une interface doivent être définies comme public (ils sont définis publics par défaut).

• Lorsque vous héritez d'une classe abstraite, un béton enfant de la classe doit définir les méthodes abstraites, alors qu'une classe abstraite peut étendre une autre classe abstraite et méthodes abstraites de la classe parent n'ont pas à être définis.

• De même, une interface étendant une autre interface n'est pas responsable de l'implémentation des méthodes à partir de l'interface parent. C'est parce que les interfaces impossible de définir une implémentation.

• Une classe enfant ne peut que étendre une seule classe (abstraite ou concrète), alors qu'une interface peut s'étendre ou qu'une classe peut implémenter plusieurs autres interfaces.

• Une classe enfant peut définir des méthodes abstraites avec la visibilité identique ou moins restrictive , alors qu'une classe implémentant une interface doit définir les méthodes avec exactement la même visibilité (publique).

Une Interface ne contient que la définition / signature de la fonctionnalité, et si nous avons des fonctionnalités communes ainsi que des signatures communes, nous devons utiliser une classe abstraite. En utilisant une classe abstraite, nous pouvons fournir un comportement ainsi que des fonctionnalités en même temps. Un autre développeur héritant de la classe abstract peut utiliser cette fonctionnalité facilement, car il n'aurait qu'à remplir les blancs.

Pris de:

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

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

Une explication peut être trouvée ici: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter-Pattern.htm

Une classe abstraite est une classe qui est que partiellement mis en œuvre par le programmeur. Il peut contenir un ou plusieurs des méthodes abstraites. Une méthode abstraite est simplement une définition de fonction qui sert à dire au programmeur que le la méthode doit être implémentée chez un enfant classe.

Un l'interface est similaire à un résumé classe; en effet, les interfaces occupent le même espace de noms que classes et abstract classe. Pour cette raison, vous ne pouvez pas définir une interface portant le même nom en tant que classe. Une interface est entièrement classe abstraite; aucune de ses méthodes sont implémentés et au lieu d'une classe sous-classement, il est dit implémentez cette interface.

De toute façon, je trouve cette explication des interfaces quelque peu déroutante. Une définition plus commune est: An interface définit un contrat que les classes d'implémentation doivent remplir. Une définition d'interface se compose de signatures de membres publics, sans aucun code d'implémentation.

Quelques différences importantes:

Sous la forme d'un tableau:

Comme indiqué par Joe de javapapers :

1.La principale différence est que les méthodes d'une interface Java sont implicitement abstraites et ne peuvent pas avoir d'implémentations. Une classe abstraite Java peut ont des méthodes d'instance qui implémente un comportement par défaut.

2.Les variables déclarées dans une interface Java sont par défaut définitives. Une classe abstraite peut contenir des variables non finales.

3.Les membres d'une interface Java sont publics par défaut. Une classe abstraite Java peut avoir les saveurs habituelles des membres de la classe comme private, protégées, etc..

4.L'interface Java doit être implémentée en utilisant le mot-clé" implements"; Une classe abstraite Java doit être étendue en utilisant le mot-clé"extends".

5.An interface peut étendre une autre interface Java uniquement, une classe abstraite peut étendre une autre classe Java et implémenter plusieurs Java interface.

6.Une classe Java peut implémentez plusieurs interfaces mais il ne peut étendre qu'une seule classe abstraite.

7.L'interface est absolument abstraite et ne peut pas être instanciée; Une classe abstraite Java ne peut pas non plus être instanciée, mais peut être invoquée si un main() existe.

8.In comparaison avec les classes abstraites java, les interfaces java sont lentes car elles nécessitent une indirection supplémentaire.

Je ne veux pas mettre en évidence les différences, qui ont déjà été dites dans de nombreuses réponses (concernant les modificateurs finaux statiques publics pour les variables dans l'interface et la prise en charge des méthodes privées protégées dans les classes abstraites)

, En termes simples, je voudrais dire:

interface: Pour implémenter un contrat par plusieurs objets non liés

classe abstraite: Pour implémenter le même comportement ou un comportement différent entre plusieurs objets connexes

De la Oracle documentation

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 de nombreuses méthodes ou champs communs, ou nécessitent des modificateurs d'accès autres que public (tels que protected et private).
3. Vous souhaitez déclarer des champs non statiques ou non définitifs.

Envisagez d'utiliser des interfaces si :

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

la classe abstraite établit une relation" est une " avec les classes concrètes. interface fournit" a " capacité pour classe.

Si vous recherchez Java comme langage de programmation, voici quelques mises à jour supplémentaires:

Java 8 a réduit l'écart entre les classes interface et abstract dans une certaine mesure en fournissant une fonctionnalité de méthode default. Une interface n'a pas d'implémentation pour une méthode n'est plus valide maintenant.

Référence à cette documentation page pour plus de détails.

Jetez un oeil à cette question SE pour des exemples de code à comprendre mieux.

Comment aurais-je dû expliquer la différence entre une Interface et une classe abstraite?

, Le point principal est que:

• Abstrait est orienté objet. Il offre les données de base qu'un "objet" devrait avoir et / ou les fonctions qu'il devrait être capable de faire. Il s'intéresse aux caractéristiques de base de l'objet: ce qu'il a et ce qu'il peut faire. Par conséquent, les objets qui héritent de la même classe abstraite partagent les caractéristiques de base (généralisation).
• L'interface est orientée fonctionnalité . Il définit les fonctionnalités qu'un objet doit avoir. Peu importe ce que l' objet c'est, tant qu'il peut faire ces fonctionnalités, qui sont définies dans l'interface, c'est bien. Il ignore tout le reste. Un objet / classe peut contenir plusieurs (groupes de) fonctionnalités; il est donc possible pour une classe d'implémenter plusieurs interfaces.

Lorsque vous souhaitez fournir un comportement polymorphe dans une hiérarchie d'héritage, utilisez des classes abstraites.

Lorsque vous voulez un comportement polymorphe pour des classes complètement indépendantes, utilisez une interface.

Je construis un immeuble de 300 étages

Le plan du bâtiment interface

• Par exemple, Servlet (I)

Bâtiment construit jusqu'à 200 étages - partiellement achevé - - - résumé

• Implémentation partielle, par exemple, servlet générique et HTTP

Construction du bâtiment terminée - béton

• Implémentation complète, par exemple, propre servlet

Interface

• Nous ne savons rien de la mise en œuvre, juste des exigences. Nous pouvons optez pour une interface.
• Chaque méthode est publique et abstraite par défaut
• C'est une classe abstraite 100% pure
• Si nous déclarons public, nous ne pouvons pas déclarer privé et protégé
• Si nous déclarons abstrait, nous ne pouvons pas déclarer final, statique, synchronisé, strictfp et natif
• Chaque interface a public, statique et final
• Sérialisation et transient n'est pas applicable, car nous ne pouvons pas créer d'instance pour in interface
• Non volatile parce qu'il est final
• Chaque variable est statique
• Lorsque nous déclarons une variable dans une interface, nous devons initialiser les variables tout en déclarant
• Instance et bloc statique non autorisés

Résumé

• mise en œuvre Partielle
• Il a une méthode abstraite. Un ajout, il utilise du béton
• Aucune restriction pour la méthode de classe abstraite modificateurs
• Aucune restriction pour les modificateurs de variable de classe abstraite
• Nous ne pouvons pas déclarer d'autres modificateurs sauf abstract
• Aucune restriction pour initialiser les variables

Extrait du site DurgaJobs

Travaillons à nouveau sur cette question:

La première chose à vous faire savoir est que 1/1 et 1*1 aboutissent à la même chose, mais cela ne signifie pas que la multiplication et la division sont identiques. Évidemment, ils ont de bonnes relations, mais attention, vous êtes tous les deux différents.

Je soulignerai les principales différences, et le reste a déjà été expliqué:

Les classes abstraites sont utiles pour modéliser une hiérarchie de classes. À première vue de toute exigence, nous sommes partiellement clairs sur quoi exactementdoit être construit, mais nous savons quoi construire. Et donc vos classes abstraites sont vos classes de base.

Les interfaces sont utiles pour permettre à d'autres hiérarchies ou classes de savoir ce que je suis capable de faire. Et quand vous dites que je suis capable de quelque chose, vous devez avoir cette capacité. Les interfaces le marqueront comme obligatoire pour qu'une classe implémente les mêmes fonctionnalités.

C'est assez simple en fait.

Vous pouvez penser à une interface d'une classe qui n'est permis d'avoir des méthodes abstraites et rien d'autre.

Ainsi, une interface ne peut que "déclarer" et ne pas définir le comportement que vous voulez que la classe ait.

Une classe abstraite vous permet à la fois de déclarer (en utilisant des méthodes abstraites) et de définir (en utilisant des implémentations de méthodes complètes) le comportement que vous souhaitez que la classe ait.

Et une classe régulière ne vous permet que de définir, pas declare, le comportement / actions que vous voulez que la classe ait.

Une dernière chose,

En Java, vous pouvez implémenter plusieurs interfaces, mais vous ne pouvez en étendre qu'une seule (Classe abstraite ou Classe)...

Cela signifie que l'héritage du comportement défini est limité à n'en autoriser qu'un par classe... c'est-à-dire que si vous vouliez une classe qui encapsule le comportement des classes A,B&C, vous devez faire ce qui suit: La classe A étend B, la classe C étend A.. c'est un peu un moyen d'en avoir plusieurs héritage...

Interfaces d'autre part, vous pouvez simplement faire: l'interface C implémente A, B

Donc, en effet, Java ne prend en charge l'héritage multiple que dans les interfaces ie "comportement déclaré", et un seul héritage avec un comportement défini.. à moins que vous ne fassiez le tour de la façon que j'ai décrite...

J'espère que cela a du sens.

La comparaison entre interface et classe abstraite est fausse. Il devrait y avoir deux autres comparaisons à la place: 1) interface vs classe et 2) résumé vs classe finale .

Interface vs Classe

Interface est un contrat entre deux objets. Par exemple, je suis facteur et vous êtes un colis à livrer. Je m'attends à ce que vous connaissiez votre adresse de livraison. Quand quelqu'un me donne un Colis, il doit connaître son adresse de livraison:

interface Package {
  String address();
}

De Catégorie est un groupe des objets qui obéissent au contrat. Par exemple, je suis une boîte du groupe "Box" et j'obéis au contrat requis par le facteur. En même temps, j'obéis à d'autres contrats:

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

Résumé vs Final

Classe Abstraite est un groupe d'objets incomplets. Ils ne peuvent pas être utilisés, car ils manquent certaines parties. Par exemple, je suis une boîte abstraite GPS-aware - Je sais comment vérifier ma position sur la carte:

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

Cette classe, si elle est héritée/étendue par une autre classe, peut être très utile. Mais par lui-même-il est inutile, car il ne peut pas avoir d'objets. Les classes abstraites peuvent être des éléments de construction de classes finales.

La classe finale est un groupe d'objets complets, qui peut être utilisé, mais ne peut pas être modifié. Ils savent exactement comment travailler et quoi faire. Par exemple, je suis une boîte qui va toujours à l'adresse spécifiée lors de sa construction:

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

Dans la plupart des langages, comme Java ou C++, il est possible d'avoir juste une classe, ni abstrait, ni définitive. Une telle classe peut être hérité et peut être instancié. Je ne pense pas que cela soit strictement conforme au paradigme orienté objet, cependant.

Encore une fois, comparer des interfaces avec des classes abstraites n'est pas correct.

La seule différence est que l'on peut participer à l'héritage multiple et que l'autre ne peut pas.

La définition d'une interface a changé au fil du temps. Pensez-vous qu'une interface n'a que des déclarations de méthode et ne sont que des contrats? Qu'en est-il des variables finales statiques et qu'en est-il des définitions par défaut après Java 8?

Ont été introduites dans Java à cause de le problème du diamant avec un héritage multiple et c'est ce qu'elles ont réellement l'intention de faire faire.

Les interfaces sont les constructions qui ont été créées pour résoudre le problème d'héritage multiple et peuvent avoir des méthodes abstraites, des définitions par défaut et des variables finales statiques.

Voir Pourquoi Java autorise-t-il les variables finales statiques dans les interfaces alors qu'elles ne sont destinées qu'à être des contrats?.

En bref, les différences sont les suivantes:

Différences syntaxiques Entre Interface et Classe abstraite:

1. Les méthodes et les membres d'une classe abstraite peuvent avoir n'importe quelle visibilité. Toutes les méthodes de interface doit être public. / / Ne tient plus vrai de Java 9
2. Une classe enfant concrète d'une classe Abstract doit définir toutes les méthodes abstraites. Une classe enfant Abstract peut avoir des méthodes abstraites. Une interface étendant une autre interface n'a pas besoin de fournir une implémentation par défaut pour les méthodes héritées de l'interface parent.
3. Une classe enfant ne peut étendre qu'une seule classe. Une interface peut étendre plusieurs interfaces. Une classe peut implémenter plusieurs interfaces.
4. Une classe enfant peut définir des méthodes abstraites avec la même visibilité ou moins restrictive, alors que la classe implémentant une interface doit définir les méthodes d'interface publique.
5. Les classes abstraites peuvent avoir des constructeurs mais pas des interfaces .
6. Les interfaces de Java 9 ont des méthodes statiques privées.

Dans les interfaces maintenant:

public static - pris en charge
public abstract - pris en charge
public default - pris en charge
private static - pris en charge
private abstract - erreur de compilation
private default - erreur de compilation
private - soutenu

Interface: Tourner ( Tourner à gauche, Tourner à Droite.)

Classe abstraite: Roue.

Classe: Volant, dérive de Roue, expose Tour d'interface

L'un sert à catégoriser le comportement qui peut être offert à travers un éventail diversifié de choses, l'autre à modéliser une ontologie des choses.

Pas vraiment la réponse à la question d'origine, mais une fois que vous avez la réponse à la différence entre eux, vous entrez dans la lorsque-pour-utiliser-chaque dilemme: Quand utiliser des interfaces ou des classes abstraites? Quand utiliser les deux?

J'ai une connaissance limitée de la POO, mais voir les interfaces comme un équivalent d'un adjectif en grammaire a fonctionné pour moi jusqu'à présent (corrigez-moi si cette méthode est fausse!). Par exemple, les noms d'interface sont comme des attributs ou des capacités que vous pouvez donner à une classe, et une classe peut en avoir beaucoup: ISerializable, ICountable, IList, ICacheable, IHappy,...

Si vous avez des méthodes communes qui peuvent être utilisées par plusieurs classes, optez pour des classes abstraites. Sinon, si vous voulez que les classes suivent un plan défini, optez pour les interfaces.

Les exemples suivants le démontrent.

Classe abstraite en Java:

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

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

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

Voici une implémentation de l'interface en Java:

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

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

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

Quelques points clés importants en un mot:

1. Les variables déclarées dans l'interface Java sont par défaut finales. Abstrait les classes peuvent avoir des variables non finales.

2. Les variables déclarées dans l'interface Java sont par défaut statique. Les classes abstraites peuvent avoir des variables statiques.

3. Les Membres d'une interface Java sont publics par défaut. Une classe abstraite Java peut avoir les saveurs habituelles des membres de la classe comme private, protected, etc..

L'héritage est utilisé à deux fins:

• Pour permettre à un objet de considérer les membres de données de type parent et les implémentations de méthode comme les siennes.

• Pour permettre à une référence à un objet d'un type d'être utilisée par un code qui attend une référence à un objet supertype.

Dans les langages/frameworks qui prennent en charge l'héritage multiple généralisé, il est souvent peu nécessaire de classer un type comme étant une "interface" ou une "classe abstraite". Populaire les langages et les frameworks, cependant, permettront à un type de considérer les membres de données ou les implémentations de méthodes d'un autre type comme les siennes, même s'ils permettent à un type d'être substituable à un nombre arbitraire d'autres types.

Les classes abstraites peuvent avoir des membres de données et des implémentations de méthodes, mais ne peuvent être héritées que par des classes qui n'héritent d'aucune autre classe. Les interfaces ne mettent presque aucune restriction sur les types qui les implémentent, mais ne peuvent inclure aucun membre de données ou méthode application.

Il y a des moments où il est utile que les types soient substituables à de nombreuses choses différentes; il y a d'autres moments où il est utile que les objets considèrent les membres de données de type parent et les implémentations de méthodes comme les leurs. Faire une distinction entre les interfaces et les classes abstraites permet à chacune de ces capacités d'être utilisée dans les cas où elle est la plus pertinente.

Points clés:

• La classe abstraite peut avoir une propriété, des champs de données ,des méthodes (complete / incomplet) les deux.
• Si la méthode ou les propriétés définissent dans le mot-clé abstrait qui doit remplacer dans la classe dérivée.(son travail comme étroitement couplé la fonctionnalité)
• Si définir un mot-clé abstrait pour la méthode ou les propriétés dans la classe abstraite, vous ne pouvez pas définir le corps de la méthode et obtenir/définir la valeur pour propriétés et qui doivent remplacer dans la classe dérivée.
• La classe abstraite ne prend pas en charge l'héritage multiple.
• La classe abstraite contient des constructeurs.
• Une classe abstraite peut contenir des modificateurs d'accès pour les sous-titres, fonctions, propriétés.
• Seul le membre complet de la classe abstraite peut être statique.
• Une interface peut hériter d'une autre interface uniquement et ne peut pas hériter d'une classe abstraite, où comme une classe abstraite peut hériter d'une autre classe abstraite ou une interface.

Avantage:

• C'est une sorte de contrat qui force toutes les sous-classes à poursuivre les mêmes hiérarchies ou normes.
• Si diverses implémentations sont du même type et utilisent un comportement ou un statut commun, alors la classe abstraite est préférable à utiliser.
• Si nous ajoutons une nouvelle méthode à une classe abstraite, nous avons la possibilité de fournir une implémentation par défaut et donc tout le code existant pourrait fonctionner correctement.
• Son permettre une exécution rapide que l'interface.(l'interface nécessite plus de temps pour trouver la méthode réelle dans le classes correspondantes.)
• Il peut être utilisé pour un couplage serré et lâche.

Retrouvez les détails ici... http://pradeepatkari.wordpress.com/2014/11/20/interface-and-abstract-class-in-c-oops/

Le moyen le plus court de le résumer est qu'un interface est:

1. Entièrement abstrait, en dehors des méthodes default et static; bien qu'il ait des définitions (signatures de méthode + implémentations) pour les méthodes default et static, il n'a que des déclarations (signatures de méthode) pour les autres méthodes.
2. Soumis à plus laxiste des règles que de classes (une classe peut implémenter plusieurs interfaces, et un interface peut hériter de plusieurs interfaces). Toutes les variables sont implicitement constantes, qu'elles soient spécifiées comme public static final ou non. Tous les membres sont implicitement public, qu'ils soient spécifiés comme tels ou non.
3. Généralement utilisé comme garantie que la classe d'implémentation aura les fonctionnalités spécifiées et/ou sera compatible avec toute autre classe qui implémente la même interface.

Pendant ce temps, une classe abstract est:

1. N'importe où de complètement abstrait à entièrement mis en œuvre, avec une tendance à avoir une ou plusieurs méthodes abstract. Peut contenir à la fois des déclarations et des définitions, avec des déclarations marquées comme abstract.
2. Une classe à part entière, et soumise aux règles qui régissent les autres classes (ne peut hériter que d'une classe), à la condition qu'elle ne puisse pas être instanciée (car il n'y a aucune garantie qu'elle est entièrement implémentée). Peut avoir des variables membres non constantes. Peut mettre en œuvre le contrôle d'accès des membres, en restreignant les membres comme protected, private, ou forfait privé (non spécifié).
3. Généralement utilisé soit pour fournir autant de l'implémentation que possible partagée par plusieurs sous-classes, ou pour fournir autant de l'implémentation que le programmeur est capable de fournir.

Ou, si nous voulons réduire tout cela à une seule phrase: Un interfaceest ce que la classe d'implémentation a, mais une classe abstractest ce que la sous-classe est.

De nombreux développeurs juniors font l'erreur de penser les interfaces, les classes abstraites et concrètes comme de légères variations de la même chose, et choisissent l'une d'entre elles uniquement pour des raisons techniques: Ai-je besoin d'un héritage multiple? Ai-je besoin d'un endroit pour mettre des méthodes communes? Ai-je besoin de m'embêter avec autre chose qu'une simple classe concrète? C'est faux, et caché dans ces questions est le problème principal: "I". Lorsque vous écrivez du code pour vous-même, par vous-même, vous avez rarement pensez à d'autres développeurs présents ou futurs travaillant sur ou avec votre code.

Les interfaces et les classes abstraites, bien qu'apparemment similaires d'un point de vue technique, ont des significations et des objectifs complètement différents.

Résumé

1. Une interface définit un contrat qu'une implémentation remplira pour vous .

2. Une classe abstraite fournit un comportement par défaut que votre mise en œuvre pouvez réutiliser.

Résumé alternatif

1. Une interface est pour définir les API publiques
2. Une classe abstraite est à usage interne, et pour définir SPIs

Sur l'importance de cacher les détails de la mise en œuvre

Une classe concrète fait le travail réel, d'une manière très spécifique. Par exemple, un ArrayList utilise une zone de mémoire contiguë pour stocker une liste d'objets de manière compacte, ce qui offre un accès aléatoire, une itération et un emplacement rapides pendant ce temps, un LinkedList utilise des nœuds à double liaison pour stocker une liste d'objets, ce qui offre plutôt une itération rapide, des changements sur place et une insertion/suppression/addition, mais est terrible à accès aléatoire. Ces deux types de listes sont optimisés pour différents cas d'utilisation, et cela compte beaucoup comment vous allez les utiliser. Lorsque vous essayez d'extraire les performances d'une liste avec laquelle vous interagissez fortement, et lorsque choisir le type de liste dépend de vous, vous devez choisir soigneusement celui que vous instanciez.

D'autre part, les utilisateurs de haut niveau d'une liste ne se soucient pas vraiment de la façon dont elle est réellement mise en œuvre, et ils devraient être isolés de ces détails. Imaginons que Java n'a pas exposé l'interface List, mais n'avait qu'une classe concrète List qui est en fait ce que LinkedList est en ce moment. Tous les développeurs Java auraient adapté leur code pour s'adapter aux détails de l'implémentation: évitez l'accès aléatoire, ajoutez un cache pour accélérer l'accès, ou réimplémentez simplement ArrayList par eux-mêmes, bien que ce soit incompatible avec tous les autres codes qui fonctionnent uniquement avec List. Ce serait terrible... Mais maintenant, imaginez que les maîtres Java se rendent compte qu'une liste chaînée est terrible pour la plupart des cas d'utilisation réels, et ont décidé de passer à une liste de tableaux pour leur seule classe List disponible. Cela affecterait les performances de tous les programmes Java dans le monde, et les gens ne seraient pas heureux à ce sujet. Et le principal coupable est que les détails de mise en œuvre étaient disponibles, et les développeurs ont supposé que ces détails sont un contrat permanent sur lequel ils peuvent compter. C'est pourquoi il est important de masquer les détails de l'implémentation et de définir uniquement un contrat abstrait. C'est le but d'une interface: définir quel type d'entrée une méthode accepte et quel type de sortie est attendu, sans exposer tous les tripes qui tenteraient les programmeurs de modifier leur code pour s'adapter aux détails internes qui pourraient changement avec une mise à jour.

Une classe abstraite est au milieu entre les interfaces et les classes concrètes. Il est censé aider les implémentations à partager du code commun ou ennuyeux. Par exemple, AbstractCollection fournit des implémentations de base pour isEmpty basées sur la taille est 0, contains comme itérer et comparer, addAll comme répété add, et ainsi de suite. Cela permet aux implémentations de se concentrer sur les parties cruciales qui les différencient: comment stocker et récupérer des données.

API versus SPIs

Les interfaces sont des passerelles à faible cohésion entre différentes parties du code. Ils permettent aux bibliothèques d'exister et d'évoluer sans casser chaque utilisateur de bibliothèque lorsque quelque chose change en interne. Il s'appelle Application Programming Interface, pas de Classes de Programmation d'Application. À plus petite échelle, ils permettent également à plusieurs développeurs de collaborer avec succès sur des projets à grande échelle, en séparant différents modules grâce à des documents bien documentés interface.

Les classes abstraites sont des helpers à haute cohésion à utiliser lors de l'implémentation d'une interface, en supposant un certain niveau de détails d'implémentation. Alternativement, des classes abstraites sont utilisées pour définir SPIs, Interfaces de fournisseur de services.

La différence entre un API et un SPI est subtile, mais importante: pour une API, l'accent est mis sur qui utilise, et pour un SPI l'accent est mis sur qui implémente il.

L'ajout de méthodes à une API est facile, tous les utilisateurs existants de l'API compileront toujours. Ajouter des méthodes à un SPI est difficile, car chaque fournisseur de services (implémentation concrète) devra implémenter les nouvelles méthodes. Si des interfaces sont utilisées pour définir un SPI, un fournisseur devra publier une nouvelle version chaque fois que le contrat SPI changera. Si des classes abstraites sont utilisées à la place, les nouvelles méthodes pourraient être définies en termes de méthodes abstraites existantes, ou en tant que talons vides throw not implemented exception, ce qui permettra au moins une ancienne version d'un implémentation du service pour toujours compiler et exécuter.

Une note sur Java 8 et les méthodes par défaut

Bien que Java 8 ait introduit des méthodes par défaut pour les interfaces, ce qui rend la ligne entre les interfaces et les classes abstraites encore plus floue, ce n'était pas pour que les implémentations puissent réutiliser le code, mais pour faciliter le changement d'interfaces qui servent à la fois d'API et de SPI (ou sont utilisées à tort

Lequel utilisez?

1. Est le chose censé être public par d'autres parties du code, ou par d'autres codes externes? Ajoutez-y une interface pour masquer les détails de l'implémentation du contrat abstrait public, qui est le comportement général de la chose.
2. Est le chose quelque chose qui est censé avoir plusieurs implémentations avec beaucoup de code en commun? Faire à la fois une interface et une implémentation abstraite et incomplète.
3. Y a-t-il ne sera jamais qu'une seule implémentation, et personne d'autre ne l'utilisera? Juste en faire un cours concret.
   1. "ever" est long, vous pouvez le jouer en toute sécurité tout en ajoutant une interface dessus.

Un corollaire: l'inverse est souvent fait à tort: lorsque vous utilisez une chose , essayez toujours d'utiliser la classe/interface la plus générique dont vous avez réellement besoin. En d'autres termes, ne déclarez pas vos variables comme ArrayList theList = new ArrayList(), sauf si vous avez réellement un très fort dépendance sur le fait qu'il s'agisse d'une liste array, et aucun autre type de liste ne le couperait pour vous. Utilisez List theList = new ArrayList à la place, ou même Collection theCollection = new ArrayList si le fait qu'il s'agisse d'une liste et non d'un autre type de collection n'a pas d'importance.

Par définition, les interfaces ne peuvent avoir d'implémentation pour aucune méthode et les variables membres ne peuvent pas être initialisées.

Cependant, les classes abstraites peuvent avoir des méthodes implémentées et des variables membres initialisées.

Utilisez des classes abstraites lorsque vous attendez des changements dans votre contrat, c'est-à-dire qu'à l'avenir, vous devrez peut-être ajouter une nouvelle méthode.

Dans cette situation, si vous décidez d'utiliser une interface, lorsque l'interface est modifiée pour inclure l'interface, votre application pause lorsque vous avez vidé la nouvelle interface dll.

Lire en détail, visitez différence entre une classe abstraite et une interface

Je voudrais ajouter une différence de plus qui a du sens. Par exemple, vous avez un cadre avec des milliers de lignes de code. Maintenant, si vous souhaitez ajouter une nouvelle fonctionnalité dans le code en utilisant une méthode enhanceUI(), il est préférable d'ajouter cette méthode dans la classe abstraite plutôt que dans l'interface. Parce que, si vous ajoutez cette méthode dans une interface, vous devez l'implémenter dans toute la classe implémentée, mais ce n'est pas le cas si vous ajoutez la méthode dans la classe abstraite.

Différences entre la classe abstraite et l'interface au nom de l'implémentation réelle.

Interface : C'est un mot-clé et il est utilisé pour définir le modèle ou l'impression bleue d'un objet et il force toutes les sous-classes à suivre le même prototype,comme pour l'implémentation, toutes les sous-classes sont libres d'implémenter la fonctionnalité selon ses exigences.

Quelques-uns des autres cas d'utilisation où nous devrions utiliser l'interface.

Communication entre deux objets externes (intégration de tiers dans notre application) effectués via Interface ici, l'interface fonctionne comme un contrat.

Abstract Class: Abstract,c'est un mot-clé et lorsque nous utilisons ce mot-clé avant toute classe, il devient abstrait class.It est principalement utilisé lorsque nous avons besoin de définir le modèle ainsi que certaines fonctionnalités par défaut d'un objet qui est suivi par toutes les sous-classes et de cette façon, il supprime le code redondant et un autre cas d'utilisation où nous pouvons utilisez la classe abstraite , comme nous voulons qu'aucune autre classe ne puisse instancier directement un objet de la classe, seules les classes dérivées peuvent utiliser la fonctionnalité.

Exemple de Classe Abstraite:

 public abstract class DesireCar
  {

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

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

  public void Wheel() {          

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


    **Here is the sub classes:**

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

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

Exemple D'Interface:

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


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

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

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

Vous pouvez trouver de différence claire entre les interface et classe abstraite.

Interface

• L'interface ne contient que des méthodes abstraites.
• Forcer les utilisateurs à implémenter toutes les méthodes lorsqu'ils implémentent l'interface.
• Ne contient que des variables finales et statiques.
• Déclarer en utilisant le mot-clé interface.
• Toutes les méthodes d'une interface doivent être définies comme publiques.
• Une interface peut s'étendre ou une classe peut implémenter plusieurs autres interface.

Classe Abstraite

• La classe Abstract contient des méthodes abstraites et non abstraites.

• Ne force pas les utilisateurs à implémenter toutes les méthodes la classe abstraite.

• Contient toutes sortes de variables, y compris primitives et non primitives

• Déclarer en utilisant le mot clé abstrait.

• Les méthodes et les membres d'une classe abstraite peuvent être définis avec tout visibilité.

• Une classe enfant ne peut étendre qu'une seule classe (abstraite ou concrète).

Voici une compréhension très basique de la classe interface vs abstract.

Une classe abstraite est une classe dont l'objet ne peut pas être créée ou une classe qui ne peut pas être instanciée. Une méthode abstraite rend une classe abstraite. Une classe abstraite doit être héritée afin de remplacer les méthodes déclarées dans la classe abstraite. Aucune restriction sur les spécificateurs d'accès. Une classe abstraite peut avoir des méthodes constructor et d'autres méthodes concrètes(non abstarct methods), mais l'interface ne peut pas en avoir.

Une interface est un modèle/modèle de méthodes.(eg. Un la maison sur un papier est donnée (maison d'interface) et différents architectes utiliseront leurs idées pour la construire(les classes d'architectes implémentant l'interface de la maison). Il s'agit d'une collection de méthodes abstraites , de méthodes par défaut , de méthodes statiques , de variables finales et de classes imbriquées. Tous les membres seront définitifs ou publics, les prescripteurs d'accès protégés et privés ne le sont pas allowed.No la création d'objet est autorisée. Une classe doit être créée pour utiliser l'interface d'implémentation et également pour remplacer la méthode abstraite déclarée dans l'interface. Une interface est un bon exemple de couplage lâche(polymorphisme dynamique/liaison dynamique) Une interface implémente le polymorphisme et abstraction.It indique quoi faire mais comment faire est défini par la classe implementing. Pour Eg. Il y a une société de voitures et elle veut que certaines fonctionnalités soient les mêmes pour toutes les voitures qu'elle fabrique, donc pour que la société fabrique un véhicule d'interface qui aura ces fonctionnalités et différentes classes de voitures (comme Maruti Suzkhi, Maruti 800) remplacera ces fonctionnalités (fonctions).

Pourquoi s'interfacer quand on a déjà une classe abstraite? Java ne prend en charge que l'héritage multiniveau et hiérarchique, mais avec l'aide de l'interface, nous pouvons implémenter l'héritage multiple.

Pour donner une réponse simple mais claire, il est utile de définir le contexte : vous utilisez les deux lorsque vous ne souhaitez pas fournir d'implémentations complètes.

La principale différence est alors qu'une interface n'a aucune implémentation (uniquement des méthodes sans corps) tandis que les classes abstraites peuvent également avoir des membres et des méthodes avec un corps, c'est-à-dire peuvent être partiellement implémentées.

Dans une interface, toutes les méthodes doivent être uniquement des définitions, pas une seule doit être implémentée.

Mais dans une classe abstraite, il doit y avoir une méthode abstraite avec seulement une définition, mais d'autres méthodes peuvent également être dans la classe abstraite avec une implémentation...

J'ai lu une explication simple mais efficace de la classe abstraite et de l'interface sur php.net

Qui est comme suit.

Une interface est comme un protocole. Il ne désigne pas le comportement de l'objet; il désigne la façon dont votre code indique à cet objet d'agir. Une interface serait comme la langue anglaise: définir une interface définit comment votre code communique avec n'importe quel objet implémentant cette interface.

Une interface est toujours un accord ou une promesse. Lorsque une classe dit "J'implémente l'interface Y", elle dit"Je promets d'avoir les mêmes méthodes publiques que tout objet avec l'interface Y".

D'autre part, une classe abstraite est comme une classe partiellement construite. C'est un peu comme un document avec des blancs à remplir. Il peut utiliser l'anglais, mais ce n'est pas aussi important que le fait qu'une partie du document est déjà écrite.

Une classe abstraite est la base d'un autre objet. Quand une classe dit "J'étends la classe abstraite Y", il dit "J'utilise des méthodes ou des propriétés déjà définies dans cette autre classe nommée Y".

Alors, considérez le PHP suivant:

<?php
class X implements Y { } // this is saying that "X" agrees to speak language "Y" with your code.

class X extends Y { } // this is saying that "X" is going to complete the partial class "Y".
?>

Vous auriez votre classe implémenter une interface particulière si vous distribuiez une classe à utiliser par d'autres personnes. L'interface est un contrat d'une série de méthodes pour votre classe.

Vous auriez votre classe étendre une classe abstraite si vous (ou quelqu'un d'autre) avez écrit une classe qui avait déjà des méthodes écrites que vous souhaitez utiliser dans votre nouvelle classe.

Ces concepts, bien que faciles à confondre, sont spécifiquement différents et distincts. Pour toutes fins utiles, si vous êtes le seul utilisateur de l'une de vos classes, vous n'avez pas besoin d'implémenter des interfaces.