Tuesday, August 31, 2010

Extension methods: what, how, when

by luisabreu via LA.NET [EN] on 8/31/2010 9:02:45 AM

I’ve already written a little bit about extension methods in the past. However, since I’ve decided to create a new basics series, I think that I probably should go back and write about it again. I guess that the first thing I need to do is define the what. In other words, *what* is an extension method?

An extension method is a static method that you can invoke using instance method syntax. Here’s a quick example:

namespace StringHelpers {
    public static class StringExtension {
        //don't need this in real world!!
        public static Boolean ContainsOnlyDigits(this String str){
            if(str == null ) throw new NullReferenceException();
            return str.All(c => char.IsDigit(c));
        }
    }
}
//use the extension method
namespace ConsoleApplication1 {
    //import extension methods
    using StringHelpers;
    class Program {
        static void Main(string[] args){
            var notOnlyDigits = "123Nop"; //const is better
            Console.WriteLine(((String)null).ContainsOnlyDigits());
        }
    }
}

As you can see, an extension method is always static and must be defined in a non generic, non nested, static class. The first parameter of an extension method is annotated with the this qualifier and defines the type over which the method can be called using an instance method syntax. In order to use the extension method (the *how*), we must first introduce it in the current scope. To achieve that, we need to resort to the using directive (as shown in the previous example).

Whenever the compiler finds an extension method, it will convert it into a static method call. Currently, you can use extension methods to extend classes, interfaces, delegates (probably more about this in a future post) and enumerate types. Internally, and since external methods aren’t C# specific, there is a “standard” way to mark a method as an extension method. In C#, when you mark a static method’s first parameter with the this qualifier, the compiler will automatically apply the ExtensionAttribute to that method and to the class where that method is defined. By annotating the type with the attribute, the compiler is able to query an assembly and get all the types that have extension methods defined.

Extension methods are really great and do improve the quality and readability of the code. However, I’ve noticed that they’re starting to be abused…for instance, it was only recently that I’ve downloaded the source code for the Fluent NH project and I couldn’t stop noticing that the CheckXXX methods (used against PersistenceSpecification instances) are all implemented as static methods. I’m having a hard time understanding this and here’s why. In my limited experience, PersistenceSpecification exists so that you can write tests for your NH mappings. Now, that means that you’ll *be* using this methods to test the mappings whenever you instantiate a new instance of that type. Since the guys that wrote the code for those methods *do* have access to the PersistenceSpecification class, I really can’t understand their decision of defining these methods as extension methods (and yes, I know that MS used the same approach for extending the IEnumberable<T> interface, but I believe that we’re not talking about the same type of scenario: after all, it’s perfectly fine to use the IEnumerable<T> without using LINQ).

So, when should we use extension methods? Here’s my thoughts about it (the *when*):

• use it *sparingly*. I really can’t stress this enough! We’re still doing OO and there are several options for extending types. Do remember that there are some versioning problems associated with extension methods. For instance, if the type you’re “extending” adds a new method with the same name as the extension method, the code will always use the instance method (after recompilation, of course) because extension methods will only be considered as candidates when all the instance method available have been considered as non-viable.
• they should look and feel like extension methods. The typical example of not following this recommendation is adding an IsNullOrEmpty extension method to some class and returning true when the “this” parameter is null (btw, here’s an example of what I mean). If the “this” parameter of the extension method is null, it should really throw a null reference exception since this is the best option for mimicking what happens with instance methods.

Overall, I’d say that extension methods are an excellent tool, but don’t get carried on and start using it everywhere. After all, we’re still writing object oriented code, right?