Pseudo-héritage multiple avec des méthodes d'extension sur les interfaces en C #?

Question

question similaire, mais pas tout à fait la même chose

Je pensais que les méthodes d'extension dans le même espace que l'interface que vous pourriez obtenir un effet similaire à l'héritage multiple dans ce que vous n'avez pas besoin d'avoir un code double mise en œuvre de la même interface de la même manière dans 10 classes différentes.

Quels sont les inconvénients de le faire? Je pense que les pros sont assez évidents, ce sont les inconvénients qui viennent généralement revenir à vous mordre plus tard.

L'un des inconvénients que je vois est que les méthodes d'extension ne peuvent pas être virtuel, donc vous devez être sûr que vous ne voulez réellement leur mise en œuvre de la même manière pour tous les cas.

Answer 1

Le problème que je vois avec une capacité d'interface de construction grâce à des méthodes d'extension est que vous n'êtes plus implémentez en fait l'interface et ne peut donc pas utiliser l'objet comme le type d'interface.

Dire que j'ai une méthode qui prend un objet de type IBar. Si j'implémentent l'interface IBar Foo classe via des méthodes d'extension, alors Foo ne dérive pas de IBar et ne peut être utilisé de manière interchangeable avec elle (Liskov principe de substitution). Bien sûr, je reçois le comportement que je veux ajouté Foo, mais je perds l'aspect le plus important de créer des interfaces en premier lieu - être en mesure de définir un contrat abstrait qui peut être mis en œuvre de diverses manières par différentes classes afin que classes dépendantes pas besoin de savoir sur les implémentations concrètes.

Si je devais l'héritage multiple (et jusqu'à présent, je l'ai vécu sans elle) assez mal, je pense que j'utiliser à la place composition pour minimiser la quantité de duplication de code.

Answer 2

Une façon décente de penser à ce sujet est que les méthodes d'instance sont quelque chose fait par l'objet, alors que les méthodes d'extension sont quelque chose fait l'objet. Je suis assez certain que les lignes directrices de conception-cadre vous devez implémenter dire une méthode d'instance chaque fois que possible.

Une interface déclare: « Je garde à l'utilisation de cette fonctionnalité, mais pas la façon dont il est accompli. » Cela laisse la liberté de implémenteurs choisir comment. Il découple l'intention, une API publique, du mécanisme, une classe avec le code béton.

Comme cela est le principal avantage des interfaces, les mettre en œuvre tout à fait comme les méthodes d'extension semble vaincre leur but. Même IEnumerable<T> a une méthode d'instance.

Modifier :, les objets sont également destinés à agir sur les données qu'ils contiennent. Les méthodes d'extension ne peuvent voir que l'API publique d'un objet (car ils ne sont que des méthodes statiques); vous devez exposer tous pour le faire fonctionner (un OO non-non) l'état d'un objet.