Extension methods were first introduced with LINQ in C#3.0. They are just a syntactic construct, but as we’ll see in this post they can make a huge difference. What’s easier to read of these two?
string[] wishList1 = Enumerable.ToArray( Enumerable.Select(Enumerable.Where(Animals, a => a.StartsWith("A")), a => string.Format("I want a {0}.", a))); string[] wishList2 = Animals.Where(a => a.StartsWith("A")) .Select(a => string.Format("I want a {0}.", a)).ToArray(); |
To me, the second alternative has several advantages:
- Get rid of the name of the helper class declaring the method. Writing out the
Enumerableclass name doesn’t add any relevant information. On the contrary, it forces the reader to actively think of it to find out that it is irrelevant. - Left-to-right reading order instead of inside-out when following the evaluation order.
- The method name and the parameters are written together. In the first example
Selectand the relevant code is splitted by the call toEnumerable.Where.
Extension methods creates a syntactic possibility to do two important things that are not allowed by the language.
- Add methods to existing classes.
- Add methods to interfaces.
Add Methods to Existing Classes
Sometimes it would be beneficial to extend existing classes with own methods. An example would be to add an IsEmail() method to the string class. The checking will be done using a regular expression, but using the name IsEmail makes the intent much more clear.
foreach (string s in strings) { if (s.IsEmail()) { Debug.WriteLine("{0} is a valid email address", (object)s); } else { Debug.WriteLine("{0} is not a valid email address", (object)s); } } |
An extension method is a static method of a static class with the first parameter marked with the this keyword. The IsEmail method is defined like this:
public static class Extensions { public static bool IsEmail(this string str) { // Regex from http://www.regular-expressions.info/email.html return Regex.IsMatch(str, "^[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,4}$", RegexOptions.IgnoreCase); } } |
Add Methods to Interfaces
Another powerful possibility with extension methods is to add methods to interfaces. The main example of this is the LINQ methods, that all operate on the IEnumerable<> interface. E.g. the Where method probably looks something like this.
public static IEnumerable<T> MyWhere<T>( this IEnumerable<T> source, Func<T, bool> filter) { foreach (T t in source) { if (filter(t)) { yield return t; } } } |
That’s some basic extension method examples. Next week I’ll show a couple of advanced techniques taking further advantage of extension methods.
Instead of using regular expressions for validating email addresses I prefer to use the
System.Net.Mail.MailAddressclass.Try to create a
new MailAddress(emailAddressToCheck)and catch any exceptions to detect invalid email addresses. If no exceptions occur, the address is valid.If you want to check if the address is for a specific domain etc you can check the properties on the created MailAddress object.
In my opinion the email example is a bad practice and code smell because the extension method is hiding the behaviour and polluting a primitive type. Consider creating a class to encapsulate the behaviour?
Extension methods are excellent for infrastructure code where you need to decorate sealed or black box types with your own behaviour for DRY, I thoroughly discourage using them with domain code, put behaviour where it belongs?
I totally agree with you that domain behaviour and validation should be carefully placed in the right layer of an application. If I had a real use case for the
IsEmailmethod I would probably place it (and any related methods) in a separate namespace, that I only referenced when needed to avoid having every string in the application being polluted with the method.What I tried to say in this post is that using an extension method with a descriptive name is much easier to read than using a regex directly.
@Albin: Using exception handling for flow-of-control is generally considered a bad practice. It can be an order of magnitude worse in terms of performance. If you’re only doing it once in a while it’s probably not a big deal, but if you implement it for some bulk import you potentially just created a bottleneck.
@Ed: Opinions are like belly buttons, everyone has one. I would prefer the extension method approach to having a whole bunch of Helper classes scattered around my project, each of which does one thing.
Nice post. Don’t let ’em get you down too much on the IsEmail() thing. I like, and I’ve done it in several projects. It’s C#’s own damn fault for not having IsMatch() on string or implementing a =~ operator like most other languages have. Making small refactoring changes to code to improve readability is awesome and needs to be encouraged. Extension methods are a part of that.
The only place where I diverge is on the how I implement the extension. I personally don’t like having extension methods that actually do stuff. So I would have an EmailValidator class with the extension method dispatching to the EmailValidator. Something like this – https://gist.github.com/2709855
Hy
There is also another significant advantage when using extension methods. It dramatically simplifies the usage when you have generic APIs in place. For example consider this interface:
Instead of calling
builder.Build()you can then leverage the power of extension methods like so:And then
builder.BuildFooWithMagic();Sorry kinda difficult to write it on the ipad :(
Daniel