Interface vs classe abstraite (général OO)

Que Diriez-vous d'une analogie: quand j'étais dans l'armée de l'Air, je suis allé à la formation de pilote et est devenu un pilote de L'USAF (US Air Force). À ce moment-là, je n'étais pas qualifié pour piloter quoi que ce soit, et j'ai dû suivre une formation sur type d'aéronef. Une fois que j'ai obtenu ma qualification, j'étais pilote (classe abstraite) et pilote de C-141 (classe concrète). À l'une de Mes affectations, on m'a confié une tâche supplémentaire: officier de sécurité. Aujourd'hui, j'étais encore pilote et pilote de C-141, mais j'ai aussi exercé des fonctions d'agent de sécurité (j'ai mis en œuvre le programme ISafetyOfficer)., façon de parler). Un pilote n'était pas tenu d'être un agent de sécurité, d'autres personnes auraient pu le faire aussi.

tous les pilotes de L'USAF doivent respecter certains règlements de la Force aérienne, et tous les pilotes de C-141 (ou de F-16, ou de T-38) sont des pilotes de l'USAF. N'importe qui peut être un officier de sécurité. Donc, pour résumer:

• Pilote: la classe abstraite
• C-141 Pilote: classe concrète
• ISafety: Agent d'interface

ajout de la note: il s'agissait d'une analogie pour aider à expliquer le concept, et non d'une recommandation de codage. Voir les différents commentaires ci-dessous, la discussion est intéressante.

je pense que la réponse qu'ils recherchent est le principe fondamental ou OPPS différence philosophique.

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

d'un autre côté, l'héritage d'interface est utilisé lorsque les classes partagent un comportement périphérique, ceux qui ne définissent pas nécessairement la classe dérivée.

, Par exemple. Une voiture et un camion partagent un grand nombre de propriétés de base et de comportement d'une classe abstraite Automobile, mais ils partagent également certains comportements périphériques comme générer des gaz d'échappement que même les classes non automobiles comme les foreuses ou les générateurs de puissance partagent et ne définit pas nécessairement une voiture ou un camion, donc Voiture, Camion, foreur et générateur de puissance peuvent tous partager la même interface IExhaust.

Bref: les classes Abstraites sont utilisés pour Modélisation une hiérarchie de classe de semblable à la recherche des classes (Par exemple, les Animaux peuvent être abstraites de la classe et de l'Homme , le Lion, le Tigre peut être en béton les classes dérivées)

et

Interface est utilisé pour Communication entre 2 classes similaires / non similaires qui ne se soucie pas du type de la classe de mise en œuvre de L'Interface(par exemple, la hauteur peut être la propriété de l'interface et il peut être mis en œuvre par L'homme , le bâtiment , L'arbre. Ça n'a pas d'importance si tu peux manger , tu peux nager, tu peux mourir ou quoi que ce soit.. il importe seulement une chose que vous avez besoin D'avoir la hauteur (la mise en œuvre dans votre classe) ).

il y a quelques autres différences -

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

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 d'établir 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 briser l'API. Les changements aux interfaces cassent les changements.

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

héritage

Considérons une voiture et un bus. Ils sont deux véhicules différents. Mais encore, ils partagent certaines propriétés communes comme ils ont une direction, freins, engrenages, moteur, etc.

Ainsi, 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 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 incomplet des objets. Pour le comprendre davantage, considérons l'analogie du véhicule une fois de plus.

Un véhicule peut être conduit. Droit? Mais différents véhicules sont conduits de différentes manières ... Par exemple, Vous ne pouvez pas conduire une voiture pendant que vous conduisez une Bicyclette.

Alors, comment représenter la fonction de commande d'un véhicule? Il est plus difficile de vérifier quel type de véhicule il s'agit et de le conduire avec sa propre fonction; vous devrez changer de classe de conducteur à plusieurs reprises lors de l'ajout d'un nouveau type de véhicule.

Voici le rôle des classes et méthodes abstraites. Vous pouvez définir la méthode d'entraînement comme abstrait pour dire que chaque héritant les enfants doivent implémenter cette fonction.

Donc si vous modifiez la classe du véhicule ...

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

le vélo et la voiture doivent également préciser comment les conduire. Sinon, le code ne se compilera pas et une erreur est lancée.

Bref.. une classe abstraite est une classe partiellement incomplète avec certaines fonctions incomplètes, que les enfants héritiers doivent spécifier leurs propres.

Interfaces Les Interfaces sont totalement incomplètes. Ils n'ont pas toutes les propriétés. Ils indiquent simplement que les enfants qui héritent sont capables de faire quelque chose ...

Supposons que vous ayez différents types de téléphones mobiles avec vous. Chacun d'entre eux a des façons différentes de faire différentes fonctions; Ex: appeler une personne. Le fabricant du téléphone indique comment le faire. Ici, les téléphones mobiles peuvent composer un numéro, il est dial-mesure. Représentons ceci comme une interface.

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

ici le fabricant du Composable définit comment composer un numéro. Vous avez juste besoin de 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);
}
.....

utilisant par la présente des interfaces au lieu de classes abstraites, l'auteur de la fonction qui utilise un Composable n'a pas à se soucier de ses propriétés. Ex: est-ce qu'il a un écran tactile ou un bloc-notes, est-ce un téléphone fixe fixe ou mobile. Vous avez juste besoin de savoir si elle est Composable; est-ce qu'elle hérite(ou implémente) Dialable interface.

et surtout , si un jour vous changez le commutateur 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 encore parfaitement parce que la fonction qui utilise le Composable ne dépend pas (et ne peut pas dépendre) des détails autres que ceux spécifiés dans l'interface Composable. Ils implémentent tous les deux une interface Composable et c'est la seule chose qui importe à la fonction.

les Interfaces sont couramment utilisées par les développeurs pour assurer l'interopérabilité(utilisation interchangeable) entre les objets, dans la mesure où ils partagent une fonction commune (tout comme vous pouvez changer de 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é.

Aussi, notez que vous pouvez implémenter (hériter) autant d'interfaces que vous voulez mais vous ne pouvez étendre(hériter) une classe monoparentale.

Plus D'Info classes abstraites vs Interfaces

si vous considérez java comme le langage OOP pour répondre à cette question, Java 8 release 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 la mise en œuvre concrète.

Oracle site web fournit les principales différences entre interface et abstract de la classe.

envisager l'utilisation des classes abstraites si:

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

envisager l'utilisation d'interfaces si:

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

En termes simples, je voudrais utiliser

interface: pour mettre en œuvre un contrat par plusieurs objets indépendants

classe abstraite: Pour mettre en œuvre les mêmes ou différents comportements entre plusieurs objets liés à l'

regardez exemple de code pour comprendre les choses de manière claire: comment aurais-je dû expliquer la différence entre une Interface et une classe abstraite?

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

une classe abstraite est une classe avec implémentation et interface (méthodes virtuelles pures) qui sera héritée. Les Interfaces n'ont généralement pas d'implémentation mais seulement des fonctions virtuelles pures.

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

en implémentant des interfaces, vous réalisez la composition (relations" has-a") au lieu de l'héritage (relations" is-a"). C'est un principe important à se rappeler 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.

j'expliquerai les détails de profondeur de l'interface et de la classe abstraite.si vous connaissez la vue d'ensemble sur l'interface et la classe abstraite, alors la première question arrive dans votre esprit quand nous devrions utiliser L'Interface et quand nous devrions utiliser la classe abstraite. Veuillez donc vérifier ci-dessous l'explication de L'Interface et de la classe abstraite.

1. quand utiliser Interface?

   si vous ne connaissez pas la mise en œuvre juste nous avons spécification d'exigence puis nous allons avec L'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 abstraite.

   Interface

   toute méthode par défaut de résumé public s'entend: l'interface est 100% pure abstraite.

   Abstrait

   peut avoir la méthode concrète et la méthode abstraite, ce qui est la méthode concrète, qui ont la mise en œuvre dans la classe abstraite, Une classe abstraite est une classe qui est déclarée abstraite-elle peut inclure ou non des méthodes abstraites.

   Interface

   nous ne pouvons pas déclarer que l'interface est privée, protégée

   Q. Pourquoi ne déclarons-nous pas Interface privée et protégée?

   parce que par défaut la méthode de l'interface est public abstract so et de sorte que la raison pour laquelle nous ne déclarons pas l'interface comme privée et protégée.

   méthode de L'Interface
   
   en outre, nous ne pouvons pas déclarer l'interface comme privée, protégée,finale,statique,synchronisée, native.....

   je vais donner la raison: pourquoi nous ne déclarez pas méthode synchronisée parce que nous ne pouvons pas créer objet d'interface et synchroniser sont travail sur l'objet so et son raison que nous ne déclarons pas la méthode synchronisée Le concept transitoire ne s'applique pas non plus parce que le travail transitoire avec synchronisé.

   Abstrait

   nous sommes heureux d'utiliser avec Public,Privé final statique.... signifie pas de restriction sont applicables dans l'abstrait.

   Interface

   Variables sont déclarées dans L'Interface comme un public final statique par défaut donc nous ne sommes pas non plus déclaré variable comme un privé, protégé.

   modificateur Volatile n'est pas non plus applicable dans l'interface parce que la variable d'interface est par défaut public statique finale et finale variable vous ne pouvez pas changer la valeur une fois qu'elle assignent la valeur en variable et une fois que vous avez déclaré la variable dans l'interface vous devez assigner la variable.

   Et de la volatilité variable, c'est de rester sur les changements de sorte qu'il est de la police provinciale. au final c'est la raison pour laquelle nous ne sommes pas utiliser volatils variable dans l'interface.

   Abstrait

   Abstrait variable pas besoin de le déclarer public static final.

j'espère que cet article est utile.

conceptuellement parlant, garder la mise en œuvre spécifique du langage, 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 code / données / propriété, bla bla, unique ou héritages multiples, tous mis à part

1 - Résumé (ou abstraite pure) Classe est destinée à mettre en œuvre la hiérarchie. Si vos objectifs d'affaires semblent quelque peu similaires structurellement, représentant un parent-enfant (hiérarchie) genre de relation seulement alors les classes d'héritage / résumé seront utilisées. Si votre modèle d'affaires n'ont pas de hiérarchie alors l'héritage ne doit pas être utilisé (ici je ne parle pas de la programmation logique par exemple, certains modèles de conception nécessitent l'héritage). Conceptuellement, la classe abstraite est une méthode pour mettre en œuvre la hiérarchie d'un modèle d'affaires dans OOP, il n'a rien à voir avec les Interfaces, en fait comparer la classe abstraite avec L'Interface est dénué de sens parce que les deux sont conceptuellement des choses totalement différentes, il est demandé dans les interviews juste pour vérifier les concepts parce qu'il semble à la fois fournir un peu la même fonctionnalité lorsque la mise en œuvre est concerné et nous les programmeurs mettent généralement plus l'accent sur le codage. [Gardez ceci à 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 elle est mise en œuvre et non héritée. Un objet commercial (faisant partie d'une hiérarchie ou non) peut avoir nombre de fonctionnalités commerciales complètes. Il n'a rien à voir avec les classes abstraites signifie l'héritage en général. Par exemple, un humain peut courir, un éléphant peut courir, un oiseau peut courir, et ainsi de suite, tous ces objets de hiérarchie différente implémenteraient l'interface RUN ou L'interface EAT or SPEAK. Ne pas aller dans la mise en œuvre que vous pourriez l'implémenter comme ayant des classes abstraites pour chaque type implémentant ces interfaces. Un objet de la hiérarchie peut avoir une fonctionnalité(interface) qui a rien à voir avec sa hiérarchie.

je crois, les Interfaces n'ont pas été inventées pour réaliser des héritages multiples ou pour exposer le comportement public, et de la même manière, les classes abstraites pures ne sont pas à l'overrulle des interfaces mais L'Interface est une fonctionnalité qu'un objet peut faire (via les fonctions de cette interface) et la classe abstraite représente un parent d'une hiérarchie pour produire des enfants ayant la structure de base (propriété+fonctionnalité) du parent

quand vous êtes si l'on pose des questions sur la différence, il s'agit en fait d'une différence conceptuelle et non d'une différence dans la mise en œuvre propre à la langue, à moins qu'on ne le demande explicitement.

je crois que les deux intervieweurs s'attendaient à une différence directe entre ces deux-là et quand vous avez échoué ils ont essayé de vous pousser vers cette différence en mettant en œuvre L'un comme l'autre

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

Pour .Net,

votre réponse au deuxième intervieweur est aussi la réponse au premier... Les classes abstraites peuvent avoir une implémentation, et l'état, les interfaces ne peuvent pas...

EDIT: sur une autre note, je n'utiliserais même pas l'expression 'subclass' (ou l'expression 'inheritance') pour décrire des classes qui sont 'définies pour implémenter' une interface. Pour moi, une interface est une définition d'un contrat qu'une classe doit se conformer si elle a été définie pour "implémenter" cette interface. Il n'hérite de rien... Tu dois tout ajouter toi-même, explicitement.

je pense qu'ils n'ont pas aimé votre réponse parce que vous avez donné les différences techniques au lieu de celles 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 de sorte que 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: est utilisé pour assurer un contrat et de faire un faible couplage entre les classes afin d'avoir une application plus maintenable, évolutive et testable.

classe abstraite: est utilisé uniquement pour factoriser du code entre les classes de la même responsabilité. Notez que c'est la principale raison pour laquelle le multi-héritage est une mauvaise chose dans OOP, parce qu'une classe ne devrait pas gérer beaucoup de responsabilités (utilisez composition à la place).

interfaces So ont un vrai rôle architectural alors que les classes abstraites ne sont presque qu'un détail d'implémentation (si vous l'utilisez correctement bien sûr).

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 indiquent clairement que si une classe abstraite ne contient que des déclarations de méthode abstraite, elle doit être déclarée en tant qu'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 des Interfaces sont par défaut publiques statiques et finales. La Question pourrait être formulée comme si toutes les variables de la classe abstraite étaient publiques. Eh bien, ils peuvent encore être non statique et non finale contrairement aux variables dans les interfaces.

Enfin I ajouterait un point de plus à ceux mentionnés ci - dessus-les classes abstraites sont encore des classes et tombent dans un arbre d'héritage unique alors que les interfaces peuvent être présentes dans l'héritage multiple.

la Différence entre Java de l'Interface et la Classe Abstraite

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 Java abstract peut avoir des méthodes d'instance qui implémentent un comportement par défaut.

2. Variables déclarées dans une interface Java est par défaut finale. Une classe abstraite peut contenir des variables non finales.

3. les membres D'une interface Java sont publics par défaut. Une classe Java abstract peut avoir les saveurs habituelles des membres de classe comme privé, protégé, etc..

4. Java interface doit être implémentée à l'aide de mot-clé "instruments"; Une classe abstraite Java devrait être étendu à l'aide du mot clé "extends".

5. Une interface peut étendre une autre interface Java seulement, une classe abstraite peut étendre une autre Classe Java et implémenter plusieurs interfaces Java.

6. une classe Java peut implémenter plusieurs interfaces mais elle ne peut étendre qu'une seule classe abstraite.

7. 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. En comparaison avec java classes abstraites, java les interfaces sont lentes, car elles nécessitent une action plus indirecte.

1. Interface:
   • nous ne mettons pas en œuvre (ou définissons) les méthodes, nous le faisons dans les classes dérivées.
   • nous ne déclarons pas les variables membres dans les interfaces.
   Les Interfaces
   • expriment la relation HAS-A. Cela signifie qu'ils sont un masque d'objets.
2. classe abstraite:
   • Nous pouvons déclarer et définir des méthodes dans la classe abstraite.
   • nous masquer les constructeurs. Cela signifie qu'il n'est pas un objet créé à partir d'elle directement.
   • classe Abstraite peut contenir des variables membres.
   • les classes dérivées héritent de la classe abstraite qui signifie que les objets des classes dérivées ne sont pas masqués, elles héritent de la classe abstraite. La relation dans ce cas est IS-A.

C'est mon opinion.

copié de CLR via C# par Jeffrey Richter...

j'entends souvent la question, " Dois-je concevoir un type de base ou une interface?"La réponse n'est pas toujours évident.

voici quelques lignes directrices qui pourraient vous aider:

■ ■ relation IS-a vs. CAN-DO un type ne peut hériter que d'une seule mise en oeuvre. Si la dérivée le type ne peut pas revendiquer une relation IS-A avec le type de base, n'utilisez pas un type de base; utilisez une interface. Interface implique une relation possible. Si la fonctionnalité NE semble appartenir avec différents types d'objets, utilisez une interface. Par exemple, un type peut convertir des instances de lui-même à un autre type (IConvertible), un type peut sérialiser une instance de lui-même (Iserialisable)), etc. Notez que les types de valeurs doivent être dérivés du système.ValueType, et donc, ils ne peuvent pas être dérivé d'une classe de base arbitraire. Dans ce cas, vous devez utiliser une relation et définir une interface.

■■ Facilité d'utilisation, Il est généralement plus facile pour vous en tant que développeur de définir un nouveau type dérivé à partir d'un type de base que d'implémenter toutes les méthodes d'une interface. Le type de base peut fournir beaucoup de fonctionnalité, donc le type dérivé n'a probablement besoin que de modifications relativement petites à son comportement. Si vous fournissez une interface, le nouveau type doit implémenter tous les membres.

■ ■ mise en oeuvre cohérente quelle que soit la qualité de la documentation relative à un contrat d'interface, il est très il est peu probable que tout le monde mette en œuvre le contrat à 100% correctement. En fait, COM souffre de ce même problème, c'est pourquoi certains objets COM ne fonctionnent correctement qu'avec Microsoft Word ou avec Windows Internet Explorer. En fournissant un type de base avec un bon mise en œuvre par défaut, vous commencez à utiliser un type qui fonctionne et est bien testé; vous pouvez alors modifier les pièces qui doivent être modifiées.

■ ■ Versioning si vous ajoutez une méthode au type de base, le type dérivé hérite la nouvelle méthode, vous commencez à utiliser un type qui fonctionne, et le code source de l'utilisateur n'a même pas besoin d'être recompilé. Ajouter un nouveau membre à une interface force l'héritier de l'interface à changer son code source et recompiler.

Interface " doit être utilisé si vous voulez impliquer une règle sur les composants qui peuvent ou ne peuvent pas être liées entre elles

Pour:

1. permet l'héritage multiple
2. Fournit une abstraction de ne pas s'exposer à ce que exactement le type d'objet est utilisé dans le contexte
3. assure la cohérence par un signature du contrat

Inconvénients:

1. doit mettre en œuvre tous les contrats définis
2. ne peut avoir de variables ou de délégués
3. une fois défini ne peut pas être modifié sans briser toutes les classes

classe de résumé : doit être utilisé lorsque vous voulez avoir une certaine base ou comportement ou implémentation par défaut pour des composants liés entre eux

Pour:

1. plus rapide que l'interface
2. dispose de flexibilité dans la mise en œuvre (vous pouvez l'implémenter entièrement ou partiellement)
3. peut être facilement changé sans briser les classes dérivées

Inconvénients:

1. ne peut pas être instancié
2. ne supporte pas l'héritage multiple

Une interface définit un contrat pour un service ou un ensemble de services. Ils fournissent le polymorphisme de manière horizontale en ce que deux classes complètement indépendantes peuvent implémenter la même interface mais être utilisées de façon interchangeable comme paramètre du type d'interface qu'elles implémentent, car les deux classes ont promis de satisfaire l'ensemble de services définis par l'interface. Les Interfaces ne fournissent aucun détail sur la mise en œuvre.

une classe abstraite définit une structure de base pour son sous-classes, et éventuellement mise en œuvre partielle. Les classes abstraites fournissent un polymorphisme vertical, mais directionnel, en ce sens que toute classe qui hérite de la classe abstraite peut être traitée comme une instance de cette classe abstraite, mais pas l'inverse. Les classes abstraites peuvent et contiennent souvent des détails d'implémentation, mais ne peuvent pas être instanciées seules - seules leurs sous-classes peuvent être "newed up".

C# permet aussi l'héritage d'interface, bien sûr.

la plupart des réponses se concentrent sur la différence technique entre classe abstraite et Interface, mais puisque techniquement, une interface est essentiellement une sorte de classe abstraite (une sans aucune donnée ou implémentation), je pense que la différence conceptuelle est beaucoup plus intéressant, et ce pourrait être ce que les enquêteurs sont après.

Un Interface est un accord . Il spécifie:"c'est comme ça qu'on va se parler". Il ne peut avoir aucune implémentation parce que ce n'est pas supposé d'avoir une implémentation. C'est un contrat. C'est comme les fichiers d'en-tête .h en C.

Un la Classe Abstraite est un mise en œuvre incomplète . Une classe peut ou ne peut pas implémenter une interface, et une classe abstraite n'a pas à l'implémenter complètement. Une classe abstraite sans aucune mise en œuvre est en quelque sorte inutile, mais totalement légal.

fondamentalement toute classe, abstraite ou non, est sur ce que est , alors qu'une interface est sur comment vous l'utilisez . Par exemple: Animal pourrait être une classe abstraite mettant en œuvre certaines fonctions métaboliques de base, et spécifiant des méthodes abstraites pour la respiration et la locomotion sans donner une mise en œuvre, parce qu'il n'a aucune idée si elle doit respirer par les branchies ou les poumons, et qu'il vole, nage, marche ou rampe. Mount , d'autre part, peut-être une Interface, ce qui indique que vous pouvez monter l'animal, sans savoir quel type d'animal, il est (ou si c'est un animal à tous!).

le fait que dans les coulisses, une interface est essentiellement une classe abstraite avec seulement des méthodes abstraites, n'a pas d'importance. Sur le plan conceptuel, ils remplissent des rôles totalement différents.

classe abstraite et différence D'Interface:

1. classe Abstraite peut avoir abstraite et non des méthodes abstraites et l'Interface peut avoir que des méthodes abstraites.
2. la classe abstraite ne supporte pas l'héritage multiple et L'Interface supporte l'héritage multiple.
3. classe Abstraite peut avoir le dernier mot, non définitif, statiques et non statiques Et variables de l'Interface a seulement statique et définitive variable.
4. classe Abstraite peut avoir des méthodes statiques, la méthode principale et le constructeur Et l'Interface ne peut pas avoir des méthodes statiques, la principale méthode ou d'un constructeur.
5. classe abstraite peut fournir la mise en œuvre de l'interface et L'Interface ne peut pas fournir la mise en œuvre de la classe abstraite.
6. le mot-clé abstrait est utilisé pour déclarer la classe abstraite et le mot-clé interface est utilisé pour déclarer l'interface.
7. résumé la classe réalise l'abstraction partielle (0 à 100%) parce qu'il y a des méthodes non abstraites aussi dans la classe abstraite alors que l'interface réalise l'abstraction complète (100%).

comme vous auriez pu obtenir les connaissances théoriques des experts, Je ne dépense pas beaucoup de mots en répétant tous ceux ici, laissez-moi plutôt expliquer avec un exemple simple où nous pouvons utiliser/ne peut pas utiliser Interface et Abstract class .

pensez à la conception d'une application à la liste de toutes les fonctionnalités de Voitures. En divers points, vous avez besoin d'héritage en commun, comme certaines des propriétés comme DigitalFuelMeter, Air conditionné, ajustement de siège, etc sont communs pour toutes les voitures. De même,nous n'avons besoin de l'héritage pour certaines classes que parce que certaines des propriétés comme le système de freinage (ABS, EBD) ne sont applicables que pour certaines voitures.

la classe ci-dessous Sert de classe de base pour tous les wagons:

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";
    }
}

considérer que nous avons une classe distincte pour chaque voiture.

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        
}

considèrent que nous avons besoin d'une méthode pour hériter la technologie de freinage pour les voitures Verna et Cruze (Non applicable pour Alto). Bien que les deux utilisent la technologie de freinage, la "technologie" est différente. Nous sommes donc en train de créer une classe abstraite dans laquelle la méthode sera déclarée abstraite et devrait être mise en œuvre dans ses classes d'enfants.

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

maintenant nous essayons d'hériter de cette classe abstraite et le type de système de freinage est mis en œuvre à Verna et 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";
    }         
}

Voir le problème dans les deux classes ci-dessus? Ils héritent de classes multiples qui C#.Net ne permet pas même si la méthode est implémentée dans les enfants. Ici, il s'agit de la nécessité de l'Interface.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

et la mise en œuvre est donnée ci-dessous:

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";
   }        
}

maintenant Verna et Cruze peuvent atteindre l'héritage multiple avec son propre type de technologies de freinage avec l'aide de L'Interface.

sont des moyens légers pour imposer un comportement particulier. C'est une façon de penser.

1) une interface peut être considérée comme une classe abstraite pure, est la même, mais malgré cela, n'est pas la même pour mettre en œuvre une interface et hériter d'une classe abstraite. Lorsque vous héritez de cette pure classe abstraite de la définition d'une hiérarchie -> héritage, si vous implémentez l'interface vous n'êtes pas, et vous pouvez mettre en œuvre autant d'interfaces que vous voulez, mais vous ne pouvez hériter d'une classe.

2) Vous pouvez définir une propriété dans une interface, de sorte que la classe qui implémente cette interface doit avoir cette propriété.

par exemple:

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

la classe qui implémente cette interface doit avoir une propriété comme ça.

bien que cette question soit assez ancienne, je voudrais ajouter un autre point en faveur des interfaces:

peuvent être injectées à l'aide de n'importe quel outil D'Injection de dépendance où une injection de classe abstraite supportée par Très peu de personnes.

réponse à la deuxième question: public variable définie dans interface est static final par défaut tandis que la public variable dans abstract classe est une variable d'instance.

à Partir de une autre réponse de la mine , portant pour la plupart sur quand utiliser l'un contre l'autre:

d'après mon expérience, les interfaces sont les meilleures utilisé lorsque vous avez plusieurs classes qui nécessitent de répondre à la même méthode ou méthodes pour qu'ils puissent être utilisé de façon interchangeable par d'autres codes qui sera écrit contre ceux interface commune des classes. Best l'utilisation d'une interface est lorsque le le protocole est important, mais le logique sous-jacente peut être différent pour chaque classe. Si vous serait autrement la duplication de la logique, considérer abstrait les classes ou l'héritage de classe standard plutôt.

types D'Interface vs. classes de base abstraites

adapté du Pro C# 5.0 et du.Net 4.5 Framework book.

Le type d'interface peut sembler très similaire à une classe de base abstraite. Rappeler que lorsqu'une classe est marquée comme abstrait, on peut définir n'importe quel nombre de membres abstraits pour fournir une interface polymorphe avec tous les types dérivés. Cependant, même lorsqu'une classe définit un ensemble de abstrait membres, il est également libre de définir n'importe quel nombre de constructeurs, données de terrain, membres non abstraits (avec la mise en œuvre), et ainsi de suite. Par contre, les Interfaces ne contiennent que des définitions abstraites des membres. L'interface polymorphique établie par une classe de parents abstraite souffre d'une limitation majeure en ce que seuls les types dérivés supportent les membres définis par le parent abstrait. Cependant, dans les grandes systèmes logiciels, il est très commun de développer des hiérarchies de classes multiples qui n'ont pas parent commun au-delà du Système.Objet. Étant donné que les membres abstraits d'une classe de base abstraite ne s'appliquent qu'aux dérivés types, nous n'avons aucun moyen de configurer les types dans différentes hiérarchies pour supporter le même polymorphic interface. Par exemple, supposons que vous ayez défini la classe abstraite suivante:

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

compte tenu de cette définition, seuls les membres qui étendent CloneableType peuvent supporter le Clone() méthode. Si vous créez un nouvel ensemble de classes qui ne s'étendent pas classe de base, tu ne peux pas gagner ça. polymorphe de l'interface. De plus, vous vous souviendrez peut-être que C# ne supporte pas les héritages multiples pour les classes. Par conséquent, si vous souhaitez créer une mini-Fourgonnette-une Voiture-un CloneableType, vous êtes incapable de le faire:

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

comme vous le devinez, les types d'interface viennent à la rescousse. Après une interface a été définie, elle peut être implémentée par une classe ou d'une structure, dans la hiérarchie, dans un espace de noms ou de toute assemblée (écrit en tout langage de programmation. net). Comme vous pouvez le voir, les interfaces sont très polymorphes. Considérez l'interface standard .NET nommée ICloneable, définie dans L'espace de noms du système. Ce interface définit une méthode unique appelée Clone ():

public interface ICloneable
{
object Clone();
}

Du Point De Vue Du Codage

une Interface peut remplacer une classe abstraite si la classe abstraite n'a que des méthodes abstraites. Autrement changer la classe abstraite en interface signifie que vous perdrez sur la réutilisation de code qui fournit L'héritage.

Du Point De Vue De La Conception

conservez-le comme classe abstraite si c'est une relation" est une " et que vous avez besoin d'un sous-ensemble ou de toute la fonctionnalité. Gardez-le comme Interface si c'est une relation" devrait faire".

décidez de ce dont vous avez besoin: juste l'application de la politique, ou la réutilisation du code et de la Politique.

bien sûr, il est important de comprendre le comportement de l'interface et de la classe abstraite en OOP (et comment les langues les gèrent), mais je pense qu'il est également important de comprendre ce que signifie exactement chaque terme. Pouvez-vous imaginer la if commande ne fonctionne pas exactement comme le sens du terme? En outre, en fait, certaines langues réduisent, encore plus, les différences entre une interface et un Abstrait... si par hasard un jour les deux termes fonctionnent presque identiques, au moins vous pouvez définissez - vous où (et pourquoi) l'un d'eux devrait-il être utilisé.

si vous lisez quelques dictionnaires et d'autres polices de caractères, vous pouvez trouver des significations différentes pour le même terme, mais ayant des définitions communes. Je pense que ces deux sens que j'ai trouvé dans ce site sont vraiment, vraiment bon et approprié.

de l'Interface:

une chose ou une circonstance qui permet de séparer et parfois éléments incompatibles pour une coordination efficace.

Résumé:

quelque chose qui concentre en soi les qualités essentielles de tout ce qui est plus étendu ou plus général, ou de plusieurs choses; essence.

exemple:

vous avez acheté une voiture et il a besoin de carburant.

votre modèle de voiture est XYZ , qui est du genre ABC , donc c'est une voiture en béton, une instance spécifique d'une voiture. Une voiture n'est pas un objet réel. En fait, c'est un ensemble abstrait des normes (qualités) pour créer un objet spécifique. En bref, Car est un classe abstraite , il est "quelque chose qui concentre en soi les qualités essentielles de tout ce qui est plus vaste ou plus général" .

Le seul carburant qui correspond à la spécification du manuel du wagon doit être utilisé pour remplir le réservoir du wagon. En réalité, il n'y a rien pour vous limiter à mettre tout le carburant, mais le moteur fonctionnera correctement seulement avec le carburant spécifié, il est donc préférable de suivre ses exigences. Les exigences de dire qu'il accepte, comme d'autres voitures du même genre ABC , un ensemble standard de carburant.

dans une vue orientée objet, carburant pour le genre ABC ne doit pas être déclaré comme une classe parce qu'il n'y a pas béton de carburant pour un genre de voitures. Bien que votre voiture pourrait accepter un carburant de classe abstraite ou carburant de véhicule, vous devez vous rappeler que votre seule partie du carburant de véhicule existant répondre à la spécification, ceux qui mettent en œuvre les exigences dans votre manuel de voiture. En bref , ils devraient mettre en œuvre le interface ABCGenreFuel , qui "... permet à des éléments séparés et parfois incompatibles de coordonner efficacement" .

Addendum

en outre, je pense que vous devriez garder à l'esprit le sens du terme classe, qui est (du même site précédemment mentionné):

Classe:

nombre de personnes ou de choses considérées comme formant un groupe en raison d'attributs, de caractéristiques, de qualités ou de traits communs; genre;

ainsi, une classe (ou une classe abstraite) ne doit pas représenter seuls les attributs communs (comme une interface), mais une sorte de groupe avec des attributs communs. Une interface n'a pas besoin de représenter une sorte. Elle doit représenter des attributs communs. De cette façon, je pense que les classes et les classes abstraites peuvent être utilisées pour représenter des choses qui ne devraient pas changer ses aspects souvent, comme un être humain un mammifère, parce qu'il représente certaines sortes. Les genres ne devraient pas changer eux-mêmes si souvent.