C# 8 - héritage multiple "classe abstraite" ?

Question

Il me semble que la fonctionnalité de C# 8.0, l'implémentation par défaut des membres de l'interface, permet essentiellement de créer des implémentations au niveau de l'interface. Si l'on ajoute à cela le fait qu'une classe peut implémenter plusieurs interfaces, cela semble étrangement proche d'une structure d'héritage multiple pour les classes. D'après ce que j'ai compris, cela semble aller à l'encontre de l'essence même de la conception du langage.

D'où vient cette divergence et quelle place laisse-t-elle aux classes abstraites ?

Cette question a été suggéré comme réponse à la mienne et bien qu'il soit utile, il ne répond pas exactement à ma question. Pour être plus précis :

• J'ai toujours pensé que l'héritage unique était l'un des principes fondamentaux de la conception de C#, c'est pourquoi la décision d'implémenter cette fonctionnalité me surprend, et je serais intéressé de savoir d'où elle vient (spécifiquement de C#).
• La question liée ne répond pas à la place qu'elle laisse aux classes abstraites.

Answer 1

J'ai toujours pensé que l'héritage unique était l'un des principes fondamentaux de la conception de C#

Ce n'est pas exact. L'héritage unique est un moyens L'objectif de l'UE est d'atteindre un objectif de conception, mais ce n'est pas un objectif en soi.

C'est comme si l'on disait que la transmission automatique est un principe de conception essentiel pour les constructeurs automobiles, alors que l'objectif réel est de rendre la voiture plus facile et plus sûre. En ce qui concerne le marché de l'automobile, les transmissions manuelles continuent de prospérer tant dans le bas de gamme (parce qu'elles sont moins chères) que dans le haut de gamme (voitures de sport performantes), où elles sont parfaitement adaptées à l'objectif visé. De nombreux modèles dans ces domaines peuvent encore être équipés de l'une ou l'autre transmission.

L'objectif réel de la conception en C#, qui conduit à l'héritage unique, concerne davantage la sécurité et l'exactitude en ce qui concerne l'accès à la mémoire et la résolution des surcharges. L'héritage multiple est difficile à vérifier mathématiquement par rapport à l'héritage simple. Mais en trouvant des solutions élégantes, les concepteurs du langage C# ont ajouté un certain nombre de fonctionnalités qui repoussent les limites de l'héritage unique. Au-delà des interfaces, nous avons les classes partielles, les génériques (et plus tard la co/contravariance), et les membres délégués qui tendent tous dans cette direction.

Dans ce cas, la mise en œuvre par défaut est effective en en toute sécurité qui constitue un héritage multiple faible, car la fonctionnalité héritée ne descend pas en cascade dans l'arbre d'héritage à partir de deux directions. Vous ne pouvez pas créer de conflit en héritant de deux classes différentes avec des implémentations d'interface différentes ; vous êtes limité soit à l'implémentation de votre propre classe, soit à l'implémentation par défaut, soit à l'implémentation unique disponible via l'héritage.

Answer 2

Notez que la mise en œuvre de l'interface par défaut ne pas permettent l'héritage multiple, du moins pas dans le sens où cela posait problème pour le C++. Les raison Le problème de l'héritage multiple en C++ est que lorsqu'une classe hérite de plusieurs classes dont les méthodes ont la même signature, il peut devenir ambigu de savoir si l'on peut hériter de plusieurs classes ou si l'on peut hériter de plusieurs classes. qui est souhaitée. Avec l'implémentation de l'interface par défaut, cette ambiguïté est impossible car la classe elle-même n'implémente pas la méthode . Un objet doit être coulé dans l'interface afin d'appeler les méthodes implémentées. Ainsi, plusieurs méthodes ayant la même signature peuvent être appelées sur la même instance, mais vous devez explicitement dire au compilateur qui que vous exécutez.

Answer 3

Le lien poste répond en grande partie à votre première question.

En ce qui concerne :

La question posée ne répond pas à la question de savoir quelle pièce abstraites.

Bien qu'elle puisse sembler similaire, la mise en œuvre de méthodes par défaut ne remplace certainement pas les classes abstraites et ne les rend pas redondantes, pour la bonne et simple raison qu'elle ne remplace pas les classes abstraites :

une interface ne peut pas définir de champs/variables au niveau de la classe, alors qu'une classe abstraite peut avoir l'état .

Il existe d'autres différences, bien qu'elles ne soient pas aussi importantes que celles mentionnées ci-dessus, que vous pouvez trouver dans divers blogs/posts :

• https://dotnetcoretutorials.com/2018/03/25/proposed-default-interface-methods-in-c-8/
• https://www.infoq.com/articles/default-interface-methods-cs8

etc.