More C# 3.0 – Extension Methods

A while back I wrote a post about lambda expressions in C# 3.0 and how they are one of the enabling technologies behind Linq. I would like to continue that discussion today with a quick overview of something called extension methods. First, I want to say up front that I believe extension methods are one of those features that will be useful for framework developers – but bring a very high risk of abuse if used widely in a general sense. So with that out of the way, I'll cover what extension methods are, how they can be used, and what are some of the "gotchas".

First, an extension method is simply a new technique for extending a class without inheriting from the class, making a partial class, etc… The really interesting thing about this technique is in the implementation details. In C# 3.0, extension methods are implemented by creating a static class (which implies that the methods will be static methods) and using the 'this' modifier on the first method parameter. For example, consider the following.

   1:  namespace LinqTestsHarness.Extensions { 

   2:    public static class TestExtensions { 

   3:      public static void SayHelloFromInt(this int arg) { 

   4:        Console.WriteLine("Hello " + arg.ToString()); 

   5:      } 

   6:    } 

   7:  }

As we have described, the extension method is identified by the fact that it is a static method (in a static class) and that it has the 'this' modifier on its first parameter. OK – so now we've go this extension method – what do we do with it? If you remember our working definition of an extension method from above, the method allows us to extend an existing type – and that's exactly what our new method does. For example, we can now run the following code.

using LinqTestsHarness.Extensions; 

... 

int n = 5; 

n.SayHelloFromInt(); 

And how did this work again? 2 things. First, we imported the namespace containing our extension method. Every time you import a namespace, you bring in every extension method that is defined within that namespace. The second important thing that allowed the above code to work is that we declared our variable (n) of type int – which is of course the type expected by our extension method. The following would not compile because of the type mismatch.

using LinqTestsHarness.Extensions; 

... 

string s = "howard"; 

n.SayHelloFromInt();

So by now you should have a pretty decent understanding of how extension methods work – so let's take a look at how they are used by Linq. Consider the following Linq expression.

IEnumerable<string> expr = from s in names 
  where s.Length == 5 
  orderby s 
  select s.ToUpper();

The Linq keyword such as 'where', 'orderby', etc… are simply shortcuts to extension methods defined in the System.Linq namespace. Therefore, the following is equivalent to the previous Linq expression.

IEnumerable<string> expr = names 
  .Where(s => s.Length == 5) 
  .OrderBy(s => s) 
  .Select(s => s.ToUpper());

So hopefully, you are now starting to see that Linq is not some sort of compiler magic. It is built on the very same language features that you have access to as you design and construct your solutions. Now, as we look at one potential application of extension methods, let me be quite clear that this is not a design pattern that I support – I am mentioning it here because I know that this is a pattern that many people do support, and if it is going to continue being used, extension methods are not a bad way to go about separating concerns. Let's consider object persistence. While there is significant debate over the "proper" architectural pattern for layer interactions, there is a school of thought that advocates the inclusion of persistence operations (Create, Read, Update, Delete) on business objects. One of the counter arguments to this approach is that you are then required to mix persistence code with business code and subsequently tie the business layer to a specific data access provider. In this context (let's forget about all of the other arguments both for and against this technique right now), extension methods provide a creative solution to the problem. For example, consider the following business entity class.

   1:  public class Person { 

   2:    private string _name; 

   3:    private int _age; 

   4:    private bool _canCode; 

   5:   

   6:    public Person() { } 

   7:   

   8:    public Person(string name) { 

   9:      Name = name; 

  10:    } 

  11:   

  12:    public Person(string name, int age) : this(name) { 

  13:      Age = age; 

  14:    } 

  15:   

  16:    public string Name { 

  17:      get { return _name; } 

  18:      set { _name = value; } 

  19:    } 

  20:   

  21:    public int Age { 

  22:      get { return _age; } 

  23:      set { _age = value; } 

  24:    } 

  25:   

  26:    public bool CanCode { 

  27:      get { return _canCode; } 

  28:      set { _canCode = value; } 

  29:    } 

  30:   

  31:    public override string ToString() { 

  32:      return Name; 

  33:    } 

  34:  }

If you wanted to maintain your data access code in a separate assembly, yet still have the appearance of data access methods on this class, you could create your data access class as a static class and use extension methods for the data access functionality. This extension class would look like the following.

namespace LinqTestsHarness.DataAccess { 
  public static class DataAccessExtensions { 
    public static void Save(this Person arg) { 
      // ... 
    }

    public static void Delete(this Person arg) { 
      // ... 
    } 
  } 
}

Just like in the previous case, using the extension method is a simple matter of importing the LinqTestsHarness.DataAccess namespace. The first parameter on the extension method constrains the method to only instances of the 'Person' class. Of course, all of the usual OO capabilities apply to extension methods. Were I using an ORM tool for my persistence, I could also create a marker interface and constrain the extension method to that interface rather than the concrete type. You can also create generic extension methods. However, my goal with this post is to simply give you an overview.

Now – a word of caution. While extension methods can be a very handy tool for allowing frameworks to add functionality to existing object models, they should probably be approached with a degree of caution. Like any cross-cutting technique, extension methods can be a real pain when it comes to tracing and debugging. One thing that you absolutely must keep in mind with extension methods is that they are given the lowest priority in terms of method invocation. Practically, this means that if the object instance already contains a method (virtual or otherwise) with the same name as your extension method, that method will always be give precedence over your extension method. Therefore, there's always going to be some degree of brittleness if you design a solution that makes heavy use of extension methods because your extension methods and the object model on which the methods are applied will probably evolve quite independently.

Secondly, and even more dangerous is the fact that although it appears as an instance methods, extension methods are of course static. What that means in IL terms is that extension methods use the 'call' instruction rather than the 'callvirt' instruction. Why is this important? Because the 'callvirt' instruction, the instruction called whenever you call an instance method on an object (in C#), checks for null and throws a 'NullReferenceException' if the object is null – the 'call' instruction does not. Therefore, the following code is perfectly legal.

Person howard = null; 
howard.Save();

Now, obviously, there are a lot of cool things that you can do with extension methods, and I'm not trying to say that you should never use them. Obviously, the Linq team has gained tremendous value from them. However, like with all things in development – just because you have a new hammer, don't turn everything into a nail!