Après avoir lu les réponses, ainsi que des questions connexes, j'ai assemblé ma compréhension de la question ici.
Comment l'extension des méthodes de travail
Tout d'abord, il est important de réaliser que les extensions sont tout sucre syntaxique pour les méthodes statiques.
// Say you have an extension method that looks like this:
class Extensions
{
public static void Extend(this SomeClass foo) {}
}
// Here's how you call it
SomeClass myClass;
myClass.Extend();
// The compiler converts it to this:
Extensions.Extend(myClass);
La méthode n'est pas réellement devenir une partie de la classe. C'est pourquoi vous ne pouvez pas accéder aux membres privés d'une méthode d'extension. Les méthodes d'Extension de changer la syntaxe C# uniquement, et ne violent pas le concept de la programmation orientée objet à l'accessibilité. En fait, si vous écrivez une méthode d'extension et d ' une méthode statique qui font la même chose, alors décompiler le MSIL, ils sont exactement la même.
Pourquoi les méthodes d'extension existent
Donc, si elles ne pas ajouter de la fonctionnalité réelle, pourquoi les méthodes d'extension à tous? La réponse est LINQ:
// LINQ makes this easy to read
array.Where(i => i&1 == 0).Select(i => i*i);
// Without extension methods, we would have to do it like this
Enumerable.Select(Enumerable.Where(array, i => i&1 == 0), i => i*i);
En un sens, tous LINQ est juste sucre syntaxique, puisque tout ce qu'il peut faire, peut être écrite dans un maladroit, non LINQy. Évidemment, l'équipe C#, estimé que la lisibilité acquise par LINQ en valait la peine, mais il pose la question, "pourquoi ont-ils arrêter là?"
Pourquoi pas d'autres types d'extension?
Eric Lippert, un de le compilateur C# devs, décrit dans un billet de blog qu'une énorme partie de C# 3 a été la création de toutes les constructions nécessaires pour LINQ: "implicitement tapé les habitants, les types anonymes, des expressions lambda, les méthodes d'extension, de l'objet et des initialiseurs de la collection, à la requête des compréhensions, des arbres d'expression, [et] l'amélioration de la méthode d'inférence de type." Parce que le C# de l'équipe a été au mieux les ressources limitées de l'équipe pour la 2008 .NET de presse, d'autres types d'extensions qui n'étaient pas strictement nécessaire pour LINQ n'ont pas été inclus.
L'équipe a examiné la mise en œuvre de l'extension de propriétés en C# 4, et a effectivement écrit un prototype de travail, mais il a été abandonné quand ils ont découvert qu'il ne permettrait pas à la WPF équipe de mise en œuvre (qui a été un des facteurs de motivation pour la fonction). Eric Lipper a dit plus tard qu'ils ont tenu compte des méthodes d'extension pour les classes statiques, mais ne pouvait pas justifier les avantages réels par rapport aux coûts de mise en œuvre, les tests et la maintenance.
Une solution de contournement
Il est possible d'écrire une méthode d'extension qui se rapproche:
public static TResult DoSomething<TType, TResult>(this TType @class)
{
// access static methods with System.Reflection
return default(TResult);
}
// This works, but poorly
typeof(Math).DoSomething();
typeof(Convert).DoSomething();
Mais c'est assez laid. Il nécessite de la réflexion, et ne peut pas supporter de frappe intelligente, puisque tout Type pouvez l'appeler comme ça et c'est probablement pas la fonctionnalité voulue.
