Possible overuses of Extension Methods

Question

I'm just coming over to .NET 3.5, and I've started using Extension Methods.

My first thought is that these are really cool. I want to use them everywhere.

I feel like I'm wielding an "Extension Method" hammer, and every piece of code looks like a nail.

I should hold myself back and ask - can anyone think of situations where you could abuse this programming technique to the detriment of the code?

Answer 1

I would say that at the point you start extracting extension methods that really belong with the class implementation is where you've gone too far. If you have to move details of the class outside the class, that's the point where you're overusing them. Other than that, I don't think they're any different than other utility methods. Extension methods just make it a little easier to extract something into a utility method and make the code very easy to read.

Answer 2

I came to the same question lately. I answered it for me this way: Is there another solution that is not too complex for the actual problem? If no I use extension methods. Sample: I have to convert LLBLgen entities to DTOs in my current project. The entities change with every change to the underlying DB but my extension methods that convert them to DTOs don't. ...and keep in mind: Do your colleagues understand (all) the extension methods you implemented by intuition?

Answer 3

I agree with jasonh. In general it may be helpful to think of extension methods not from the point on when not to use them but when to use them and it will be easier to spot wrong usage.

When you find that your design calls for making an interface definition that many classes will be forced to implement, consider creating the smallest possible set of members defined in the interface. Then provide an implementation of convenience methods in the form of extension methods. In that way, class designers who implement your interface will have the least amount of work to do, and developers using your interface can get the greatest possible benefit.

"More Effective C#: 50 Specific Ways to Improve Your C#"

Answer 4

I never put application-specific logic in an extension method for a non-application-specific type. Extension methods can get "lost" so to say, so you have to be very careful when you create them. Here's what I've used them for:

• COM interop calls that have an out parameter but could just as easily simply return the value from the call. For example "int GetValue(out object pValue)" becomes "object GetValue(this IComInterfaceType o)"
• Wrapping ridiculously complicated code sequences in the Visual Studio API. For example, once you have the Class View tool pane object, locating an object in it is ridiculous, so I wrote a helper that takes sane parameters and does it. All the functionality is available in the Class View interface(s), it's just not always clear how to use it.
• Allowing "instance calls" on a null object... in a particular section of I wanted empty IEnumerable<T> sequences (Enumerable.Empty<T>()) instead of null. The code had a single entry method for each sequence, but it was called in many dozens of locations. So I made the extension handle null as empty instead. Please don't just use this because it's a "neat idea." I exhausted several other options before going with this.

In other words: I use extension methods only to exposed existing general functionality of an object that has such a "clumsy" API that the additional complexity of keeping track of the extension method pales in comparison to attempting to perform the operation other wise. These types are often characterized by the fact that I'll only use the extension methods when operating on them, such that putting it in a Utilities-type class would almost render the type as POD. If the type has a usable API on its own and I'm adding a niche feature, I generally won't make it an extension method.

Answer 5

I personally haven't seen enough uses of extension methods for there to be an over use of them...