Skip to content
- 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.