Comment le manque d'héritage multiple de C # a-t-il conduit à la nécessité d'interfaces?

Question

Dans Le Langage de Programmation C# Krzysztof Cwalina unis dans une annotation:

nous avons décidé de ne pas ajouter le support de l'héritage multiple [...] l'absence d'héritage multiple nous a obligé à ajouter la notion de interfaces, qui sont responsables de problèmes avec la l'évolution du cadre, au plus profond des hiérarchies d'héritage, et de nombreux d'autres problèmes.

Les Interfaces sont un concept de base de la programmation orientée-objet les langues. Je ne suis pas la signification de "nous a obligé à ajouter la notion d'interfaces"

Ne Krzysztof dire que certaines décisions de conception a dû être faite concernant l'utilisation des interfaces dans les cas où de multiples héritage serait-il utilisé? Ou ne fait-il dire que, interfaces'a été introduit pour C# en raison de l'absence d'héritage multiple? Pouvez-vous me donner un exemple?

Answer 1

Une interface est simplement une classe de base qui n'a pas de membres de données et définit seulement public abstract méthodes. Par exemple, ce serait une interface en C++:

class IFrobbable {
    public:
    virtual void Frob() = 0;
}

Par conséquent, lorsque MI est disponible en tant que langue fonctionnalité, vous pouvez "mettre en œuvre" des interfaces simplement en dérivant (encore une fois, C++):

class Widget : public IFrobbable, public IBrappable {
    // ...
}

L'héritage Multiple dans le cas général, donne lieu à de nombreuses questions et problèmes qui ne sont pas nécessairement une réponse unique, ou même un bon pour votre définition de "bonne" (redouté diamant, anyone?). Plusieurs implémentation de l'interface laisse de côté la plupart de ces problèmes exactement parce que le concept "d'hériter" d'une interface est une très contraint cas particulier de l'héritage d'une véritable classe.

Et c'est là que "nous a obligé à ajouter la notion d'interfaces": vous ne pouvez pas faire beaucoup OO design lorsqu'il est contraint à l'héritage simple, par exemple il y a de sérieuses questions à ne pas être en mesure de réutiliser du code lors de la réutilisation de code est en fait l'un des arguments les plus courants pour OO. Que vous avez à faire quelque chose de plus, et la prochaine étape est l'ajout de l'héritage multiple, mais seulement pour les classes qui satisfont les contraintes d'une interface.

Donc, je interpréter Krzysztof du cite comme disant

L'héritage Multiple dans le cas général est un très épineux problème nous ne pouvions pas aborder de manière satisfaisante compte tenu de la vie réelle les contraintes sur le développement de l' .NET. Cependant, l'héritage de l'interface est à la fois beaucoup plus simple à aborder et d'une importance suprême dans la POO, donc nous n'avons mis que dans. Mais bien sûr, les interfaces sont également dotées de leur propre ensemble de problèmes, principalement en ce qui concerne la façon dont la BCL est structuré.

Answer 2

De Chris Brumme:

Il y a un certain nombre de raisons pour nous de ne pas mettre en œuvre de Multiples La mise en œuvre de l'Héritage directement. (Comme vous le savez, nous soutenons Plusieurs L'Héritage De L'Interface).

Je pense que ce Krzysztof Cwalina états dans le devis n'est pas le concept des interfaces de lui-même, mais Plusieurs l'héritage de l'interface comme une méthode de l'héritage multiple.

Il ya plusieurs raisons que nous n'avons pas fourni une boulangerie, vérifiables, CLS version compatible avec plusieurs de la mise en œuvre de l'héritage:

1. Différentes langues effectivement avoir des attentes différentes pour comment MI œuvres. Par exemple, comment les conflits sont réglés et si doublon les bases sont fusionnées ou redondantes. Avant que nous puissions mettre en œuvre des MI dans le CLR, nous avons à faire un sondage auprès de toutes les langues, figure hors du commun concepts, et de décider de la façon de les exprimer dans une langue de manière neutre. On devra aussi décider si MI appartient au CEMAT et ce cela signifierait pour les langues qui ne veulent pas ce concept (sans doute VB.NET, par exemple). Bien sûr, c'est l'entreprise, nous sommes dans un common language runtime, mais nous n'avons pas eu à le faire pour MI encore.

2. Le nombre de lieux où MI est vraiment approprié est en fait assez petite. Dans de nombreux cas, plusieurs héritage de l'interface peut obtenir la travail fait à la place. Dans d'autres cas, vous pourriez être en mesure d'utiliser l'encapsulation et de la délégation. Si nous devions ajouter un peu différente de construire, comme mixin, ce serait justement d'être le plus puissant?

3. Plusieurs mise en œuvre de l'héritage injecte beaucoup de complexité dans la mise en œuvre. Cette incidence de la complexité de la coulée, la mise en page, l'expédition, sur le terrain, la sérialisation, l'identité des comparaisons, la vérifiabilité, la réflexion, les génériques, et probablement beaucoup d'autres des lieux.

Answer 3

Je pense que vous devriez lire ce qu'Eric Lippert dit à propos de l' Interfaces . Il a eu ses mains dans le cambouis, donc je pense qu'il sait mieux que tout le monde.

Parfois, il y a pire des cas et le pire des cas. Vous avez à choisir la moins mauvaise.

Ci-dessous est une copie de la poste:

---

Ils sont là juste pour s'assurer que ces fonctions (dans le interface) sont mis en œuvre dans la classe qui hérite.

Correct. C'est suffisamment impressionnant d'avantages pour justifier la fonctionnalité. Comme d'autres l'ont dit, une interface est une obligation contractuelle de mettre en œuvre certaines des méthodes, propriétés et événements. L'irrésistible avantage d'un langage statiquement typé, c'est que le compilateur peut vérifier qu'un contrat qui votre code s'appuie sur le est en fait atteint.

Cela dit, les interfaces sont assez faibles pour représenter des obligations contractuelles. Si vous voulez une plus forte et plus flexible pour représenter les obligations contractuelles, regarder dans le Code des Contrats de fonctionnalité livré avec la dernière version de Visual Studio.

C# est un langage parfait, mais parfois, il vous donne le sentiment que première Microsoft crée le problème(et non pas ce qui permet à plusieurs l'héritage), puis fournit la solution, qui est plutôt un fastidieux.

Eh bien, je suis content que vous l'aimez.

Tous les logiciels complexes dessins sont le résultat de la pesée caractéristiques contradictoires les uns contre les autres, et essayer de trouver le "sweet spot" qui donne de grands avantages pour les petits frais. Nous avons appris par l'expérience douloureuse que les langues qui permettent à l'héritage multiple, aux fins de la mise en œuvre le partage des avantages relativement minimes et relativement importante des coûts. Le permet l'héritage multiple uniquement sur les interfaces qui ne sont pas de partager les détails de mise en œuvre, donne de nombreux avantages de l'héritage multiple, sans que la plupart des coûts.

Answer 4

Je pense que Cwalina de la langue est un peu fort, et pas tout à fait exacte au sujet de l'histoire.

Rappelez-vous que les interfaces ont été autour avant de C#, pour ainsi dire "nous avons dû ajouter des interfaces pour résoudre le problème x" n'est pas bonne pour moi. Je pense que les interfaces aurait été il y a, par défaut, ils auraient dû être.

Aussi, n'oubliez pas que le C# est issue en grande partie à partir de C++. Ou, au moins, les personnes impliquées dans la création du langage C# aurait eu très solides antécédents en C++. L'Héritage Multiple a été reconnu que le cauchemar de la zone en C++. Hériter de plusieurs classes qui eux-mêmes peuvent être dérivées à partir de commonm classes de base, la mise en œuvre a préséance sur l'autre etc. Je veux dire, c'est une fonctionnalité très puissante, mais peut sans doute conduire à un code complexe.

Je soupçonne qu'ils ont laissé tomber l'héritage multiple en C#, parce qu'ils (les auteurs de langue) savait comment embrouillé tout peut devenir et qu'ils voulaient éviter. Gardez à l'esprit également que lorsque C# a été introduit l'un de ses points de vente était sa propreté (à fairless pas plus propre que Java, mais beaucoup plus propre que le C et le C++).

Par ailleurs, en+ de 10 ans de développement C#, j'ai seulement voulu pour l'héritage multiple fois. Un composant de l'INTERFACE utilisateur que j'ai voulu hériter à la fois un style visuel et certaines communes de comportement. Il ne me fallut pas longtemps pour réaliser que ce que j'avais l'intention de le faire aurait été une assez horrible design en tout cas.