Disadvantages of extension methods?

Question

Extension method is a really helpful feature that you can add a lot of functions you want in any class. But I am wondering if there is any disadvantage that might bring troubles to me. Any comments or suggestions?

Answer 1

As far as disadvantages go, I would see them a bit like macros - you can potentially end up with code that is harder to maintain because others might not be familiar with the extensions you added.

Answer 2

Extension methods are fun, but there are potential problems with them. For instance, what if you write an extension method and another library creates an extension method with the same signature? You will end up with difficulties in using both namespaces.

Also, it can be argued that they are less discoverable. I think it depends on this one. In some cases your code should be wrapped up in a class, in other cases it's fine to add that functionality as an extension method.

I generally make extension methods as wrappers to my own classes or BCL classes, and put them in a different name space. e.g. Utils and Utils.Extensions. That way the extesions don't have to be used.

Answer 3

Couple of things:

• It's not always clear as to where the extension method comes from unless you are inside VS.NET
• Extension methods can't be resolved via reflection or C# 4.0's dynamic lookup

Answer 4

• The way that extension methods are imported (i.e. a whole namespace at a time) isn't granular. You can't import one extension from a namespace without getting all the rest.
• It's not immediately obvious from the source code where the method is defined. This is also an advantage - it means you can make your code look consistent with the rest of the methods on the type, even if you can't put it in the same place for whatever reason. In other words, the code is simpler to understand at a high level, but more complicated in terms of exactly what's being executed. I'd argue this is true of LINQ in general, too.
• You can only have extension methods, not properties, indexers, operators, constructors etc.
• If you're extending a 3rd party class and in a later version they introduce a new method with the same signature, you won't easily know that the meaning of your calling code has changed. If the new method is very similar to your extension, but with subtly different boundary conditions (or whatever) then this could lead to some very tricky bugs. It's relatively unlikely to happen though.

Answer 5

• The null-checking with static methods is different. Not necessarily better or worse - but different, and the developer needs to understand that. Being able to call a method on a null value can be unexpected, and can (at times) be very useful.

• No polymorphism (although overloading is supported)

• You can get into a mess with ambiguity if two extension methods conflict for the source type (and neither qualifies as "better"). The compiler then refuses to use either... which means adding an extension method in assembly A can break* unrelated code in assembly B. I've seen this a couple of times...

• You can't use in with C# 2.0, so if you are writing a library for C# 2.0 it doesn't help

• It needs [ExtensionAttribute] - so if you are writing a library for .NET 2.0 you get into a pickle: if you declare your own [ExtensionAttribute], it might conflict from a .NET 3.5 caller

Don't get me wrong though - I'm a big fan!

You can probably guess I'm currently writing a library that needs to work for C# 2.0 and .NET 2.0 callers - and where (annoyingly) extension methods would be really, really useful!

*=for the compiler only; code that is already compiled will be fine