What are the best practices for using Extension Methods in .Net?

Question

I have seen these being used every which way, and have been accused of using them the wrong way (though in that case, I was using them that way to demonstrate a point).

So, what do you think are the best practices for employing Extension Methods?

Should development teams create a library of extension methods and deploy them across various projects?

Should there be a collection of common extension methods in the form of an open source project?

Update: have decided to create an organization wide extension methods library

Answer 1

The upcoming release of the Framework Design Guidelines, 2nd Edition will have some guidance for implementing extension methods, but in general:

You should only define extension methods "where they make semantic sense" and are providing helper functionality relevant to every implementation.

You also should avoid extending System.Object as not all .NET languages will be able to call the extension method as an extension. (VB.NET for instance would need to call it as a regular static method on the static extension class.)

Don't define an extension method in the same namespace as the extended type unless you're extending an interface.

Don't define an extension method with the same signature as a "real" method since it will never be called.

Answer 2

you might want to take a look at http://www.codeplex.com/nxl and http://www.codeplex.com/umbrella which are both extension method libraries. I personally haven't had a look at the source code but I'm sure the guys there would be able to give you some good pointers.

Answer 3

I've been including my extension methods in with my Core libraries in the Utils class because people who are working with my framework are likely to find the methods useful, but for mass deployment where the end developer might have a choice of extension method libraries, I would advise putting all of your extensions into their own namespace, even their own project file, so that people can choose to add a reference or a using statement or simply where required, like so:

Core.Extensions.Base64Encode(str);

My Utils class is my bestest friend in the whole world, it was before extension methods came along and they have only helped to strengthen our relationship. The biggest rule I would go by is to give people choice over what extension framework they are using where possible.

Answer 4

The Objective-C language has had "Categories" since the early 1990s; these are essentially the same thing as .NET Extension Methods. When looking for best practices you might want to see what rules of thumb Objective-C (Cocoa & NeXT) developers have come up with around them.

Brent Simmons (the author of the NetNewsWire RSS reader for Mac OS X and iPhone) just posted today about his new style rules for the use of categories and there's been a bit of discussion in the Cocoa community around that post.

Answer 5

I think that it depends on what purpose the Extension methods serve.

• Extension methods that relate to specific business needs of a project (whether they are connected to basic data types or custom objects) should not be included in a library that would be distributed across multiple projects.
• Extension methods that relate to basic data types (int, string, etc) or generics that have a wider application could be packaged and distributed across projects.

Take care not to globally include Extension methods that have little application, as they just clog up intellisense and can lead to confusion and/or misuse.

Answer 6

When I first found out about Extensions I really overused and abused them.

For the most part I have started to get away from using any Extension Methods for a number of reasons.

Some of the reasons I stopped using them are noted in Scott's blog link above, such as "Think twice before extending types you don't own". If you have no control over the source for the types you are extending, you may encounter issues/collisions in the future if the source type has some additions/changes, such as moving your project to a newer .NET version. If the newer .NET version includes a method on the type of the same name as your extension, someone is going to get clobbered.

The main reason why I stopped using Extension Methods is that you can't quickly tell from reading the code where the source of the method is and who "owns" it.

When just reading through the code you can't tell whether the method is an extension or just a standard NET API method on the type.

The intellisense menu can get really messy really fast.