Pourquoi les méthodes magiques ont-elles été implémentées en C #?

En C #, j'ai commencé à voir toutes ces méthodes magiques surgir, sans être sauvegardées par une interface. Pourquoi a-t-il été choisi?

Laissez-moi expliquer.

Auparavant en C #, si un objet implémentait l' IEnumerableinterface, il serait automatiquement itérable par une foreachboucle. Cela a du sens pour moi, car il est soutenu par une interface, et si je devais avoir ma propre Iteratorfonction dans la classe en cours d'itération, je pourrais le faire sans craindre que cela signifierait par magie autre chose.

Maintenant, apparemment, (je ne sais pas quand), ces interfaces ne sont plus nécessaires. Il a juste besoin d'avoir les bonnes conversions de noms.

Un autre exemple est de rendre n'importe quel objet attendable en ayant une méthode nommée exactement GetAwaiter qui a quelques propriétés spécifiques.

Pourquoi ne pas créer une interface comme ils l'ont fait avec IEnumerableou INotifyPropertyChangedsauvegarder cette "magie" statiquement?

Plus de détails sur ce que je veux dire ici:

http://blog.nem.ec/2014/01/01/magic-methods-c-sharp/

Quels sont les avantages et les inconvénients des méthodes magiques, et y a-t-il un endroit en ligne où je peux trouver des informations sur les raisons pour lesquelles ces décisions ont été prises?

En général, des «méthodes magiques» sont utilisées lorsqu'il n'est pas possible de créer une interface qui fonctionnerait de la même manière.

Quand il a foreachété introduit pour la première fois en C # 1.0 (ce comportement n'est certainement pas récent), il a dû utiliser des méthodes magiques, car il n'y avait pas de génériques. Les options étaient essentiellement:

1. Utilisez le non générique IEnumerableet IEnumeratorcela fonctionne avec objects, ce qui signifie des types de valeur de boxe. Étant donné que l'itération de quelque chose comme une liste de ints devrait être très rapide et ne devrait certainement pas créer beaucoup de valeurs de boîte à ordures, ce n'est pas un bon choix.

2. Attendez les génériques. Cela signifierait probablement retarder .Net 1.0 (ou au moins foreach) de plus de 3 ans.

3. Utilisez des méthodes magiques.

Donc, ils ont choisi l'option # 3 et elle est restée avec nous pour des raisons de compatibilité descendante, même si depuis .Net 2.0, l'exigence IEnumerable<T>aurait également fonctionné.

Les initialiseurs de collection peuvent avoir un aspect différent sur chaque type de collection. Comparez List<T>:

public void Add(T item)

et Dictionary<TKey, TValue>:

public void Add(TKey key, TValue value)

Vous ne pouvez pas avoir une seule interface qui prendrait en charge uniquement le premier formulaire pour List<T>et uniquement le second pour Dictionary<TKey, TValue>.

Les méthodes LINQ sont généralement implémentées en tant que méthodes d'extension (de sorte qu'il ne peut y avoir qu'une seule implémentation de LINQ to Object pour tous les types qui l'implémentent IEnumerable<T>), ce qui signifie qu'il n'est pas possible d'utiliser une interface.

Pour await, la GetResult()méthode peut renvoyer voidun type ou un type T. Encore une fois, vous ne pouvez pas avoir une seule interface capable de gérer les deux. Bien qu'il awaitsoit partiellement basé sur l'interface: l'attente doit implémenter INotifyCompletionet peut également implémenter ICriticalNotifyCompletion.