.NET 3.o provides the feature named “Extension methods”, which is used drastically by the LINQ library. For example, the Enumerable class of System.Linq namespace declares a whole bunch of static extension methods that allows user to write Linq enabled smart looking methods on any IEnumerable instance.
For instance,
Generates output like following
Here, we are using the Where method which is basically an extension method for any IEnumerable instance. The extension methods along with the Lambda expression (which is another new feature of .NET 3.0), allows us to write very verbose filter code like snippet showed above.
Here, we are using the Where method which is basically an extension method for any IEnumerable instance. The extension methods along with the Lambda expression (which is another new feature of .NET 3.0), allows us to write very verbose filter code like snippet showed above.
So, what is the Extension method?
According to the MSDN,
“Extension methods enable you to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.”
“Extension methods enable you to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type. For client code written in C# and Visual Basic, there is no apparent difference between calling an extension method and the methods that are actually defined in a type.”
I personally like this feature very much. Along with the LINQ related usage Extension methods can be very handy in some other cases.
Consider a scenario, where I have an interface that has a method with three arguments.
Consider a scenario, where I have an interface that has a method with three arguments.
Now at some point, I found that it would be better to provide an overload of this method where the last argument will not present, the implementation of the interface will pass true as the default value of indent.
Now, if I do so, each of the implementers of this interface need to implement the handy overloaded version and need provide the default value true. But this seems a burden that we could take away from the implementers. Also, there are chances that somebody will implement this second method and pass false mistakenly as a default.
We can resolve this issue very neat way using extension method. Consider the following snippet.
See, the interface only contains one version of the method, implementers are also not bothered at all about the overloading version and the default value jargons. But the consumer of the interface still consuming this as this is a part of the interface, only they need to import the namespace where the extension method declared. Even the Visual Studio is also providing the result intellisense support like a regular overloaded scenario. Isn’t it nice?
Now, if I do so, each of the implementers of this interface need to implement the handy overloaded version and need provide the default value true. But this seems a burden that we could take away from the implementers. Also, there are chances that somebody will implement this second method and pass false mistakenly as a default.
We can resolve this issue very neat way using extension method. Consider the following snippet.
See, the interface only contains one version of the method, implementers are also not bothered at all about the overloading version and the default value jargons. But the consumer of the interface still consuming this as this is a part of the interface, only they need to import the namespace where the extension method declared. Even the Visual Studio is also providing the result intellisense support like a regular overloaded scenario. Isn’t it nice?
Internally, what is happening? Well, this is basically a syntactical sugar, not more than that. The compiler actually generates the regular static method calls for the extension methods. Therefore, compiler actually interprets that syntax as following
So this is a compile time stuffs, during runtime, it’s nothing different from a regular static method invocation.
Like C# Visual basic also supports extension methods. But there is an exception though. Don’t use the extension method invocation syntax for any extension method that written for System.Object class . Because VB consider the System.Object class differently, and it will not generate this actual static method invocation syntax during compile time. And what will happen actually is, during runtime it will raise an exception. So be aware about it.
This feature is really a great one among the other features of .NET 3.0, we can now write some common boiler-plate codes as an extension method in an enterprise solutions. For instance, methods like, ArgumentHelper.ThrowExceptionIfNull(), String.IsNullOrEmpty() can be written with extension methods and can be used in a very handy way.
Like C# Visual basic also supports extension methods. But there is an exception though. Don’t use the extension method invocation syntax for any extension method that written for System.Object class . Because VB consider the System.Object class differently, and it will not generate this actual static method invocation syntax during compile time. And what will happen actually is, during runtime it will raise an exception. So be aware about it.
This feature is really a great one among the other features of .NET 3.0, we can now write some common boiler-plate codes as an extension method in an enterprise solutions. For instance, methods like, ArgumentHelper.ThrowExceptionIfNull(), String.IsNullOrEmpty() can be written with extension methods and can be used in a very handy way.
Big power has big responsibilities.
As this offer you a lot of power to write methods for any type, you need to remain aware that you are not writing unnecessary extension methods which can make other confused. Such as writing a lot of extension methods for System.Object is definitely not a good idea.
I’m expecting something called “Extension properties” which could be another good thing. I think, it should not be a difficult one, cause internally .NET properties are basically nothing but methods. Hope Microsoft will ship “Extension properties” in future version of .NET framework.
Happy programming!
Reverse Engineering 
Hi
Thanks for your nice blog post. One thing i need to hear from you. Microsoft is already added some programming language features like partial class, extension method, partial method etc. That way we can extend our component functionality. But one thing i saw that we are someway bypassing true object oriented style like class inheritance, method overriding/overloading etc. So I want to know is Microsoft’s approach is ok?
LikeLike
@A Habib:
Using Partial Methods, Classes or extension methods are not violation of OOP in any sense. All of these are purely syntactic suger..nothing more than that. They are translated into regular static methods..and things like that which is perfectly okay in a OOP guideline.
Thnx
LikeLike