Introduction à la différence entre les interfaces et les classes dans .NET

Les interfaces et les classes sont souvent utilisées dans notre développement quotidien. Quelle est la différence entre les deux ? Quels sont les avantages et les inconvénients ? L'article suivant vous présentera des informations pertinentes sur la différence entre les interfaces et les classes dans .NET. Les amis qui en ont besoin peuvent s'y référer.

Préface

Tout le monde devrait savoir que .Net fournit une interface différente de la définition de type de Class ou Struct. Dans certains cas, les interfaces semblent être identiques aux classes abstraites, c'est pourquoi certaines personnes pensent que les classes abstraites peuvent être complètement remplacées par des interfaces dans .Net. En fait, ce n’est pas le cas. Les interfaces et les classes abstraites ont chacune leurs propres forces et faiblesses, elles sont donc souvent utilisées en combinaison dans des applications pour se compléter. Pas grand chose à dire ci-dessous, jetons un œil à l’introduction détaillée.

Parlons ensuite de la différence entre les classes abstraites et les interfaces :

Différence 1. Les concepts exprimés par les deux sont différents. La classe abstraite est un degré élevé d'agrégation d'une classe de choses, donc pour les sous-classes qui héritent de classes abstraites, c'est une relation "oui" ; les interfaces définissent des spécifications comportementales, donc pour les sous-classes qui implémentent des interfaces, par rapport à l'interface, c'est " le comportement doit être complété en fonction de l'interface." Cela peut paraître un peu faux, mais voici un exemple. Par exemple, chien est un terme général désignant tous les animaux canins, le Pékinois est un chien et le Berger est un chien. Ensuite, les caractéristiques générales des chiens se retrouveront chez le Pékinois et le Berger. Ainsi, par rapport au Pékinois et au Berger, le chien appartient. le type abstrait de ce genre de chose ; quant à l'action d'« aboyer », les chiens peuvent aboyer et les oiseaux peuvent aussi aboyer. Évidemment, la première équivaut à la classe abstraite, tandis que la seconde fait référence à l’interface.

Différence 2 : lors de la définition d'une méthode de type pour une classe abstraite, la partie implémentation de la méthode peut ou non être donnée ; tandis que pour une interface, la partie implémentation ne peut être donnée pour aucune méthode qui y est définie.

Par exemple :

publicabstractclassAbsTest
{
publicvirtualvoidTest()
{
Debug.WriteLine("Test");
}
publicabstractvoidNewTest();
}
publicinterfaceITest
{
voidTest();
voidNewTest();
}

Différence trois, les classes d'héritage ont des implémentations différentes des méthodes impliquées dans les deux. La classe héritée n'a pas besoin de réécrire les méthodes abstraites définies par la classe abstraite, c'est-à-dire que les méthodes de la classe abstraite peuvent être étendues ; pour les méthodes ou attributs définis par la classe d'interface, les méthodes correspondantes doivent être données dans la classe héritée. Les méthodes et propriétés sont implémentées.

La quatrième différence est que dans une classe abstraite, si une nouvelle méthode est ajoutée, la classe héritée n'a pas besoin d'être utilisée pour aucun traitement pour les interfaces, la classe héritée doit être modifiée pour fournir une nouvelle méthode ; méthode définie.

Maintenant que nous connaissons la différence entre les deux, parlons des avantages des interfaces par rapport aux classes abstraites.

Avantage 1 : Les interfaces peuvent non seulement agir sur les types référence, mais également sur les types valeur. Quant aux classes abstraites, elles ne peuvent agir que sur des types référence.

Avantage 2 : l'héritage de type .Net ne peut être qu'un héritage unique, ce qui signifie qu'un type ne peut hériter que d'un seul type, mais peut hériter de plusieurs interfaces. En fait, je suis d'accord avec ce point. L'héritage multiple rendra l'arbre d'héritage déroutant.

Avantage 3 : étant donné que les interfaces définissent uniquement des propriétés et des méthodes et ont peu à voir avec les types réellement implémentés, les interfaces peuvent être réutilisées par plusieurs types. En revanche, la relation entre les classes abstraites et les classes héritées est plus étroite.

Avantage 4 : grâce aux interfaces, vous pouvez réduire les attributs et les méthodes exposés par un type, ce qui facilite la protection des objets de type. Lorsqu'un type qui implémente une interface peut contenir d'autres méthodes ou attributs, mais lorsque la méthode renvoie, il peut renvoyer l'objet d'interface de cette manière, l'extrémité appelante ne peut accéder aux éléments pertinents de l'objet que via les méthodes ou attributs fournis par. L'interface, qui peut protéger efficacement l'objet.

Avantage 5 : Réduisez les opérations de déballage des types valeur. Pour les données de type valeur définies par Struct, lorsqu'elles sont stockées dans une collection, elles doivent être déballées à chaque fois qu'elles sont retirées. Dans ce cas, la méthode de combinaison Struct+Interface est utilisée pour réduire l'opération de déballage.

Par rapport aux classes abstraites, les interfaces présentent de nombreux avantages, mais les interfaces ont une faiblesse fatale, c'est-à-dire que les méthodes et propriétés définies par l'interface ne peuvent être relatives qu'au type qui en hérite (à moins qu'elles ne soient modifiées dans le classe héritée) étiquette de fonction définie par l'interface), alors lorsqu'il s'agit de relations d'héritage multicouches, il est difficile de l'implémenter en utilisant uniquement les interfaces. Parce que si chaque type hérite de l'interface et l'implémente, sans compter que l'écriture de code est plus lourde, et parfois le résultat de l'exécution est erroné, surtout lorsque l'objet de sous-type est implicitement converti en objet de classe de base pour l'accès.

À l'heure actuelle, il doit être implémenté à l'aide d'interfaces combinées à des méthodes virtuelles. En fait, en héritage, faut-il utiliser des interfaces ou des classes abstraites ? L'interface est fixe et conventionnelle, donc l'implémentation des méthodes et propriétés correspondantes de l'interface doit être fournie dans la classe héritée. Pour les classes abstraites, l'implémentation de la méthode de définition de la classe abstraite traverse tout l'arbre d'héritage, donc l'implémentation ou la réécriture des méthodes est incertaine. Par conséquent, relativement parlant, les classes abstraites sont plus flexibles que les interfaces.

Un simple tableau de comparaison entre les deux est donné ci-dessous.

	Interface	Classe abstraite
Héritage multiple	Supporté	Non pris en charge
Restrictions de type	Non	Oui, il ne peut s'agir que d'une méthode de type référence
méthode implémentation	L'implémentation de la méthode doit être donnée dans le type hérité	Il n'est pas nécessaire de la donner dans la classe héritée
Extensibilité	Compliqué	Relativement flexible
L'héritage multi-niveaux	est plus gênant et nécessite l'utilisation de fonctions virtuelles	qui sont plus flexible

En général, les interfaces et les classes abstraites sont des moyens de langage fournis par .Net pour mieux réaliser la relation d'héritage entre les types, et les deux sont quelque peu complémentaires de l'un l'autre. Par conséquent, je n'insiste pas sur ce qu'il faut utiliser et sur ce qu'il ne faut pas utiliser. La clé du problème est de savoir comment appliquer raisonnablement ces deux méthodes au programme.

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!