Extension methods are a powerful feature in .NET, and have been increasingly adopted by the developer community. Also, LINQ and other framework features rely heavily on extension methods. In fact, extension methods were originally invented to be able to implement LINQ without having to change a lot of .NET framework base classes.
Basically, an extension method is implemented as a static method on a static class. For those of you who have never seen an extension method in real life, the first parameter in the signature of an extension method might look a bit peculiar.
This first parameter typed with the keyword this is just syntactic sugar to be able to tell for which type the extension method is valid. In this example it is valid for any instances of the type Task, and all of its subtypes.
Like using a regular method?
Using the extension method seems exactly like using a regular method on such instances, as in the example below.
But there’s a slight difference. Since the extension method is not implemented on the type itself, it is unable to reference the private parts of the type. Moreover, the extension method can only be called only on instances of the specific type, and not statically on the type itself.
Object extension methods
So far, so good. Now, as I said earlier, the developer community has warm embraced this cool .NET feature. In fact, when you browse for extension method on the internet, there’s tons of useful – and useless – extension methods available. If you look really careful, most of these are either defined as valid for object of string.
This is where the 42 anti-pattern comes from. Sometimes it’s hard to define the best location for an extension method. In the example of the Execute() methode above we couldn’t make up our minds – should it be valid for Task or for DomainObject?
In such case I can imagine that there will be developers out there who will now define the method on object, allowing the extension method to be applied from any arbitrary object in the application, clearly not what extension methods are intended.
And this is where things are starting to dive of the deep end. Not only will you end up with a whole bunch of method that have nothing to do with most objects in your application, it can get even worse when you don’t have an object in your application that I can use to call the extension method on. What to do now?
Well, what if you would just define an arbitruary object hosting the extension method. Good idea dudes! We’ll just define the int instance 42 – just to have some fun and the method on 42.
Isn’t that sweet? I’m curious to see how long it takes until we find such code.