扩展方法如何挂钩

Question

I was just curious to know how Extension methods are hooked up to the Original class. I know in IL code it gives a call to Static Method, but how it does that and why dosen't it break encapsulation.

Answer 1

They don't "hook up".

The Visaul Studio IDE just makes it look like it does by showing them in the intellisense lists.

The compiler "knows" how to deal with the references in order to make the right method calls with the correct parameters.

This is simply syntactic sugar - the methods are simply static methods on a separate static class. Using the this modifier lets the compiler "know" to add the ExtensionAttribute to the class to mark it as an extension method.

Since extension methods do not in fact change the class and can only access public members on it, encapsulation is retained.

From MSDN :

Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type.

(emphasis mine)

Answer 2

Extension methods are specified by putting the this keyword in front of the first parameter of a static method:

public static void SomeExtension(this string s)
{
    ...
}

That is just syntactic sugar for decorating the method with System.Runtime.CompilerServices.ExtensionAttribute :

[Extension]
public static void SomeExtension(string s)
{
    ...
}

When the compiler sees that attribute, it knows to translate the extension method call to the appropriate static method call, passing the instance as the first parameter.

Since the calls are just normal static method calls, there is no chance to break encapsulation; the methods, like all static methods, only have access to the public interfaces of the extended types.

Answer 3

Extension methods are just syntactic sugar, they are just static methods. You are only able to access public fields or properties in them, just like normal static methods.

Answer 4

The key ingredient is that an instance method of a class isn't fundamentally different from a static method. With one small detail, they have a hidden argument. For example, the String.IndexOf(char) method actually looks like this to the CLR:

public static int IndexOf(string thisRef, char value) {
   // etc...
}

The thisRef argument is what supplies the string reference whenever you use this in your code or access a member of the class. As you can see, it is a very small step from an extension method to an instance method. No changes were necessary in the CLR to support the feature.

One other minor difference is that the compiler emits code that checks if this is null for an instance method but does not do so for an extension method. You can call an extension method on a null object. While that might look like a feature, it is actually a restriction induced by the extension method not actually being a member of the class.

Internally, the CLR keeps a list of methods for the class, the MethodTable. Extension methods are not in them, preventing the compiler from emitting the callvirt IL instruction, the 'trick' that it uses to get the cheap null check. Explicitly emitting code to make the null check would have been possible but they elected not to do so. Not quite sure why.

Another automatic consequence of this is that an extension method cannot be virtual.

Answer 5

我想你应该看看http://go.microsoft.com/fwlink/?LinkId=112388