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

There are two different scenarios where extension methods come into play:

1. If you want to extend any class, struct of interface coming from an external assembly, except for the classes which are not marked as sealed where you may have an option to derive from those classes and extend them with additional methods, you have only and I repeat only this option available. Sealed classes and struct can not be inherited and point less to mention interfaces.

2. In your own assembly, however, providing an extension method to a particular class or struct or interface is a very design subjective matter. If you want to be generious to people who will use your assembly you may create very small interfaces ideally with few properties and then attach whole bunch of extension methods to them. Here is the example:

   public interface IPointF{
       float X { get; }
       float Y { get; }
   }
   
   public struct PointF: IPointF{
       public PointF(float x, float y){
           X=x;Y=y;
       }
       public float X { get; private set; }
       public float Y { get; private set; }
   }
   
   public static class PointHelper{
       public static PointF ADD(this IPointF p, float val){
           return new PointF(p.x+val, p.y+val);
       }
   }
   

So any future user can save lot of time in coding by inheriting IPoint.

Answer 2

Its hard for me to imagine to add a method without knowing intimately about an existing code. For example, you've been using a third-party class to do something, what would be the need for you to extend functionality of this class given that you're not the original developer and you have no ideas how things are structured in the class? It's almost pointless to do such a thing just like it's pointless to drive when you can't see. In the case LINQ where it's implemented by Microsoft designers/codes, it made a lot of sense since they possess the knowledge of how say an internal of implementation of a sequence and now they want to extend its functionality by adding the Count method to count all the elements in the sequence. By having said this, I wish someone would argue me wrong by giving a realistic example where extension method is needed.

Answer 3

• 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

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

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 6

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 7

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.