Interprétation 1
En C#, abstrait et virtuel sont déroutants, tous deux liés à l’héritage, et impliquent l’utilisation de la dérogation. Discutons des différences entre les deux :
1. Méthode virtuelle
Le mot-clé virtuel est utilisé pour modifier les méthodes de la classe de base. Il existe deux situations où le virtuel est utilisé :
Scénario 1 : Une méthode virtuelle est définie dans la classe de base, mais la méthode virtuelle n’est pas réécrite dans la classe déduite. Dans l’appel à l’instance de classe dérivée, la méthode virtuelle utilise la méthode définie par la classe de base.
Scénario 2 : Une méthode virtuelle est définie dans la classe de base, puis la méthode est réécrite en utilisant le contournement dans la classe déduitive. Dans l’appel à l’instance de classe dérivée, la méthode virtuelle utilise la méthode de réécriture dérivée.
2. Méthode abstraite (méthode abstraite)
Le mot-clé abstrait ne peut être utilisé que dans des classes abstraites pour modifier des méthodes, et il n’existe pas d’implémentation spécifique. L’implémentation des méthodes abstraites doit être réalisée en utilisant le mot-clé de remplacement dans la classe déduitive.
La différence la plus essentielle entre une interface et une classe abstraite : une classe abstraite est une classe incomplète, une abstraction d’un objet, tandis qu’une interface est une norme comportementale.
3. Mots-clés
Statique : Lorsqu’une méthode est déclarée comme statique, elle est une méthode statique et le compilateur conserve l’implémentation de la méthode au moment de la compilation. C’est-à-dire que la méthode appartient à une classe, mais pas à un membre, qu’une instance de la classe existe ou non. Tout comme la fonction d’entrée Static void Main, parce qu’il s’agit d’une fonction statique, elle peut être appelée directement.
Virtua : Lorsqu’une méthode est déclarée Virtuelle, c’est une méthode virtuelle jusqu’à ce que vous utilisiez la variable ClassName = new ClassName() ; Avant de déclarer une instance d’une classe, elle n’existe pas dans l’espace mémoire réel. Ce mot-clé est très couramment utilisé en héritage de classes pour fournir un support polymorphiste pour les méthodes de classes.
override : indique une réécriture Cette classe hérite de la classe Shape Virtuel, abstrait, c’est dire aux autres classes qui veulent hériter de lui que vous pouvez passer outre cette méthode ou propriété de ma part, sinon ce n’est pas autorisé. Résumé : La déclaration de méthode abstraite est une méthode qui doit être supplantée par une classe dérivée, qui sert à hériter ; On peut la considérer comme une méthode imaginaire sans réalisation ; Si une classe contient une méthode abstraite, alors la classe doit être définie comme une classe abstraite, qu’elle contienne ou non d’autres méthodes générales ; Les classes abstraites ne peuvent pas contenir de substances.
a) La méthode de la modification virtuelle doit avoir une implémentation de méthode (même si ce n’est qu’une paire d’entretoises), et la méthode de la modification abstraite ne peut pas avoir d’implémentation.
b) le virtuel peut être réécrit par des sous-classes, le résumé doit être réécrit par des sous-classes
c) Si une fonction d’une classe est modifiée par abstrait, le nom de la classe doit aussi être modifié par abstact
d) Les classes abstraites modifiées ne peuvent pas être créées comme des instances.
e) Si une méthode en C# est prête à réécrire la classe parent dans la sous-classe, la méthode doit être modifiée avec virtuel dans la classe parent et overiser dans la sous-classe, évitant ainsi que le programmeur réécrive accidentellement la méthode parent de la classe parent dans la sous-classe.
Note : Les classes modifiées avec abstract ne peuvent être qu’héritées, pas instanciées.
Interprétation 2
Les termes virtuel et abstrait sont tous deux utilisés pour modifier la classe parente, permettant de redéfinir la classe enfant en supplantant la définition de la classe parente.
Ils ont un point commun : s’ils sont utilisés pour modifier des méthodes, public doit être ajouté devant, sinon il y aura des erreurs de compilation : les méthodes virtuelles ou abstraites ne peuvent pas être privées. Après tout, ajouter virtuel ou abstrait permet de redéfinir la sous-classe, et les membres privés ne peuvent pas être accessibles par la sous-classe.
Mais ils sont très différents. (virtuel est « virtuel », abstrait est « abstrait »).
(1) La méthode de modification virtuelle doit être implémentée (même si elle n’ajoute qu’une paire d’appareils), tandis que la méthode de modification abstraite ne doit pas être implémentée. Par exemple, si la méthode de modification virtuelle n’est pas implémentée :
Erreur : « Test1.fun1() » doit déclarer le corps car il n’est pas marqué comme abstrait, externe ou partiel
Pour les modificateurs abstraits, si implémentés :
Erreur : « Test2.fun2() » ne peut pas déclarer le corps car il est marqué comme abstrait
(2) le virtuel peut être réécrit par des sous-classes, tandis que le terme abstrait doit être réécrit par des sous-classes.
Il n’y a pas d’erreur lors de la compilation, si la méthode du modificateur virtuel est réécrite, il faut ajouter un override devant (ce qui indique au compilateur que vous souhaitez réécrire la méthode virtuelle), et il doit y avoir une implémentation, sinon la compilation sera erronée :
(3) Si un membre de classe est modifié par abstrait, abstract doit être ajouté avant la classe, car seules les classes abstraites peuvent avoir des méthodes abstraites.
(4) Les instances de classes abstraites ne peuvent pas être créées, elles ne peuvent être qu’héritées et ne peuvent pas être instanciées, par exemple : BaseTest2 base2 = nouveau BaseTest2() ; Il y aura une erreur de compilation : la classe abstraite ou l’interface ne peut pas créer d’instance.
(5) En C#, si vous souhaitez réécrire une méthode dans une sous-classe, vous devez ajouter virtuel avant la méthode parent et override avant la méthode de la sous-classe, afin d’éviter que les programmeurs ne réécrivent accidentellement la méthode parent dans la sous-classe.
(6) La méthode abstraite doit être écrasée, et la méthode virtuelle doit avoir une implémentation (même si c’est une méthode définie dans la classe abstraite).
Interprétation 3 Similarités : 1. Ils peuvent tous être hérités 2. Aucun d’eux ne peut être instancié 3. Il peut contenir des déclarations de méthode 4. Les classes dérivées doivent implémenter des méthodes non réalisées Distinguer: 1. Les classes de base abstraites peuvent définir des champs, des attributs et des implémentations de méthodes. Les interfaces ne peuvent définir que des attributs, indexeurs, événements et déclarations de méthodes, et ne peuvent pas contenir de champs. 2. Une classe abstraite est une classe incomplète qui doit être affinée davantage, tandis qu’une interface est une norme comportementale. Les interfaces personnalisées de Microsoft sont toujours accompagnées d’un champ capable de prouver qu’elles sont des expressions du « Je peux le faire... » ” 3. Les interfaces peuvent être implémentées plusieurs fois, et les classes abstraites ne peuvent être héritées que par une seule personne 4. Les classes abstraites sont plus définies entre une série de classes étroitement liées, tandis que la plupart des interfaces sont vaguement liées mais implémentent toutes une certaine fonction 5. Les classes abstraites sont des concepts abstraits à partir d’une série d’objets apparentés, ils reflètent donc la communauté interne des choses ; Une interface est une convention fonctionnelle définie pour satisfaire les appels externes, elle reflète donc les caractéristiques externes des choses 6. L’interface n’a en fait aucune caractéristique spécifique d’hérédité, elle promet seulement une méthode qui peut être appelée 7. L’interface peut être utilisée pour supporter les rappels, mais l’héritage ne possède pas cette fonctionnalité 8. Les méthodes spécifiques implémentées par les classes abstraites sont virtuelles par défaut, mais les méthodes d’interface dans la classe qui implémentent l’interface ne sont pas virtuelles par défaut, bien sûr, vous pouvez aussi les déclarer virtuelles 9. Si la classe abstraite implémente l’interface, la méthode dans l’interface peut être mappée à la classe abstraite comme méthode abstraite sans avoir à l’implémenter, mais la méthode dans l’interface peut être implémentée dans la sous-classe de la classe abstraite Règles d’utilisation : 1. Les classes abstraites sont principalement utilisées pour des objets étroitement liés, tandis que les interfaces sont mieux utilisées pour fournir une fonctionnalité générale aux classes non pertinentes 2. Si vous souhaitez concevoir une grande unité fonctionnelle, utilisez des classes abstraites ; Si vous voulez concevoir de petits blocs fonctionnels concis, utilisez des interfaces. 3. Si plusieurs versions du composant sont censées être créées, créez une classe abstraite. Une fois qu’une interface est créée, elle ne peut plus être modifiée. Si une nouvelle version de l’interface est nécessaire, une toute nouvelle interface doit être créée. 4. Si la fonction créée doit être utilisée entre un large éventail d’objets hétérogènes, utiliser l’interface ; Si vous souhaitez fournir une fonctionnalité implémentée commune à toutes les implémentations d’un composant, utilisez des classes abstraites. 5. Analyser l’objet, affiner la communauté interne pour former une classe abstraite, qui sert à exprimer l’essence de l’objet, c’est-à-dire le « quoi ». Les interfaces sont priorisées lorsque des appels ou fonctions externes doivent être étendus 6. Une bonne définition d’interface doit être spécifique et fonctionnelle, non multifonctionnelle, sinon elle provoquera une pollution d’interface. Si une classe n’implémente qu’une seule fonction de l’interface, mais doit implémenter d’autres méthodes dans l’interface, cela s’appelle la pollution de l’interface 7. Essayez d’éviter d’utiliser l’héritage pour obtenir la fonction de formation, mais utilisez le multiplexage boîte noire, c’est-à-dire la combinaison d’objets. En raison de l’augmentation du nombre de niveaux d’héritage, la conséquence la plus directe est que lorsque vous appelez une classe dans ce taxon, vous devez tous les charger dans la pile ! Les conséquences sont imaginables. (Combiné à la compréhension du principe de la pile). En même temps, des amis intéressés peuvent remarquer que Microsoft utilise souvent la méthode de la combinaison d’objets lors de la création d’une classe. Par exemple, dans asp.net, la classe Page possède des propriétés telles que Requête de serveur, mais en réalité ce sont toutes des objets d’une certaine classe. Utiliser cet objet de la classe Page pour appeler les méthodes et propriétés d’autres classes est un principe de conception très basique Par exemple: Les formulaires de fenêtre peuvent être conçus avec des classes abstraites, et les opérations publiques ainsi que les propriétés peuvent être placées dans une classe abstraite, de sorte que la forme et la boîte de dialogue puissent hériter de cette classe abstraite, puis s’étendre et s’améliorer selon leurs propres besoins.
L’opération d’impression peut être fournie comme une interface à chaque formulaire nécessitant cette fonction, car le contenu du formulaire est différent, et ils doivent implémenter leur propre fonction d’impression selon leurs propres besoins. Lors de l’impression, il n’est appelé que via l’interface, quel que soit le formulaire imprimé.
Points communs, individualité et choix : Certains livres indiquent que C# recommande d’utiliser des interfaces plutôt que des classes de base abstraites, et soulignent les nombreux avantages d’utiliser des interfaces, avec lesquels je ne suis pas en désaccord, ; d’après la liste ci-dessus, il existe encore de nombreuses différences entre les deux, et l’existence de cette différence doit déterminer la différence dans les scénarios applicables, par exemple, dans la classe de base abstraite, qui peut fournir des implémentations par défaut pour certaines méthodes, afin d’éviter leur implémentation répétée dans les sous-classes et d’améliorer la réutilisabilité du code. C’est l’avantage des classes abstraites ; L’interface ne peut contenir que des méthodes abstraites. Quant au moment où utiliser des classes de base abstraites et quand utiliser des interfaces, cela dépend de la façon dont les utilisateurs perçoivent les liens entre classes héritées, qu’il s’agisse de différences de personnalité ou de connexions communes entre elles. Permettez-moi d’illustrer avec un exemple de vie.
Si on vous donne trois objets, à savoir les humains, les poissons et les grenouilles, et qu’on vous demande de concevoir une catégorie de base pour qu’ils résument la connexion entre eux, alors la première chose que vous ressentirez est qu’il existe de grandes différences entre eux, et qu’il est difficile d’en abstraire les points communs. C’est là que vous devriez envisager d’utiliser des interfaces plutôt que des classes de base abstraites pour trois raisons :
1. L’individualité est plus importante que la commune. 2. Les personnalités présentant de grandes différences ont certains des mêmes comportements. 3. Il existe de grandes différences dans les méthodes de réalisation d’un même comportement. À ce stade, on vous donne trois objets supplémentaires, à savoir la carpe croisée, la carpe et le poisson rouge, et vous pouvez toujours concevoir des classes de base pour résumer la connexion entre elles, puis la première chose que vous réalisez est qu’ils appartiennent tous aux poissons, et la seconde est que leur façon de nager peut être légèrement différente, donc vous devriez utiliser des classes de base abstraites au lieu d’interfaces, comparé à l’exemple ci-dessus, il y a trois raisons :
1. La communauté est plus grande que l’individualité 2. Les individus partageant les mêmes points communs doivent avoir les mêmes attributs et comportements 3. Il existe certaines différences dans les méthodes d’implémentation du même comportement Parmi les nombreuses raisons d’utiliser des interfaces ou des classes de base abstraites, la troisième raison est en réalité la même, qui décrit le concept de polymorphisme dans l’orienté objet, c’est-à-dire qu’il est implémenté en supplantant la classe parent et en appelant la méthode correspondante à l’exécution selon la référence d’objet passée. La seconde raison commence à diverger, les interfaces mettant l’accent sur le même comportement entre objets hérités, tandis que les classes abstraites mettent également l’accent sur les mêmes propriétés entre objets hérités. Ce qui distingue vraiment les interfaces des classes de base abstraites, ce sont les raisons suivantes :
Les interfaces sont utilisées lorsqu’on recherche une compatibilité fonctionnelle entre des objets présentant de grandes différences. Les classes de base abstraites sont utilisées lorsque des différences fonctionnelles sont recherchées entre des objets ayant plus de points communs. En comparant les mêmes et différents, on ne peut qu’affirmer que les interfaces et les classes abstraites ont leurs propres forces, mais qu’il n’y a aucun avantage. Dans la pratique de la programmation réelle, nous devons mesurer nos talents selon la situation spécifique, mais l’expérience et l’accumulation suivantes peuvent vous inspirer, en plus de certaines de mes accumulations, beaucoup viennent des classiques, je crois qu’elles peuvent résister à l’épreuve. Ainsi, dans les règles et les occasions, nous apprenons ces classiques, la chose la plus importante est d’appliquer ce que nous avons appris, bien sûr, je ferai rire tout le monde avec les paroles d’une famille, continuez s’il vous plaît.
Règles et occasions : 1. Rappelez-vous que l’un des principes les plus importants de la pensée orientée objet est : la programmation orientée interface. 2. Avec l’aide d’interfaces et de classes abstraites, de nombreuses idées des 23 patrons de conception ont été habilement implémentées, et je pense que leur essence réside simplement dans le fait qu’elles sont orientées vers la programmation abstraite. 3. Les classes abstraites doivent principalement être utilisées pour des objets étroitement liés, tandis que les interfaces sont mieux utilisées pour fournir des fonctionnalités générales pour des classes non pertinentes. 4. L’interface se concentre sur le type de relation CAN-DO, tandis que la classe abstraite se concentre sur la relation IS-A. 5. Le comportement des objets multi-définis dans l’interface ; les classes abstraites définissent plusieurs fois les propriétés des objets ; 6. Les définitions d’interface peuvent utiliser des modificateurs publics, protégés, internes et privés, mais presque toutes les interfaces sont définies comme publiques, il n’est donc pas nécessaire d’en dire plus. 7. « L’interface reste inchangée » est un facteur important à prendre en compte. Par conséquent, lors de l’ajout d’extensions à partir d’interfaces, de nouvelles interfaces doivent être ajoutées, et non des interfaces existantes. 8. Essayez de concevoir l’interface en un bloc fonctionnel avec une seule fonction, prenant .NET Framework comme exemple : IDisposable, IDisposable, IComparable, IEquatable, IEnumerable, etc. ne contiennent qu’une seule méthode commune. 9. La lettre majuscule « I » devant le nom de l’interface est une convention, tout comme le nom du champ commence par un soulignement, veuillez respecter ces principes. 10. Dans l’interface, toutes les méthodes sont par défaut publiques. 11. Si des problèmes de version sont attendus, vous pouvez créer une « classe abstraite ». Par exemple, si vous créez un chien, une poule et un canard, vous devriez envisager d’abstraire les animaux pour gérer des situations qui pourraient survenir à l’avenir. L’ajout de nouveaux membres à l’interface oblige toutes les classes dérivées à être modifiées et recompilées, de sorte que les problèmes de versionnement sont mieux réalisés avec des classes abstraites. 12. Les classes non abstraites dérivées de classes abstraites doivent inclure toutes les méthodes abstraites héritées et les implémentations réelles d’accesseurs abstraits. 13. Le nouveau mot-clé ne peut pas être utilisé pour les classes abstraites, ni être scellées, car les classes abstraites ne peuvent pas être instanciées. 14. Les modificateurs statiques ou virtuels ne peuvent pas être utilisés dans des déclarations de méthodes abstraites.
|