C# extension methods design patterns and usage guidelines?

Question

C# extension methods have seen a rise in usage over recent years. The offical microsoft guidelines on usage state: "In general, we recommend that you implement extension methods sparingly and only when you have to" The extension method guidelines.

On the other hand Microsoft are now using them heavily in dot net core (see the microsoft extensions name space). This is particularly prevalent is asp core where the initializaion of the IServiceCollection is implemented in extension methods, for example see The service collection service extensions. Dot net core tutorials has an article listing this as a design pattern suggesting that it is best practice. Quite a few popular nuget packages also use this method to initialise services: Swagger is configured this way microsoft docs as well as mediatr their implementation

Should the guidelines be updated or should this practice be avoided? If the guidelines are to be updated what should they be?

Answer 1

Extension methods are just syntactic sugar for ordinary static method calls.

Extension methods make possible the ability to "spot-weld" methods onto existing types, without requiring inheritance, composition, weaving or any other language mechanisms. But they're just a proxy for an ordinary method call; they don't participate in the design of the class, nor do they add any new functionality that the class doesn't already have.

What an extension method does is turn this:

Manager.Foo(bar);

into this:

bar.Foo();

And that's all it really does.

It's arguably prettier (which is no small thing), but really, is there any other compelling reason to use extension methods?

Yes: to enable Method Chaining.

var productList = products
   .Where(prod => prod.StateOfManufacture = "CA")
   .OrderBy(prod => prod.Category)
   .ThenByDescending(prod => prod.UnitPrice)
   .Select(prod => new 
        { Name = prod.ProductName, Category = prod.Category, Price = prod.UnitPrice });

This would be very tedious without extension methods.

The advice "use extension methods sparingly, and only when you have to" is not actionable. Entire libraries and frameworks have been built using extension methods, and you never "have to."

So is it a "best practice?" My answer to that is "does it most effectively meet your specific needs?"

Answer 2

The goal of extension methods is specifically to be able to extend either classes of other assemblies or interfaces. The recommendation to use them sparingly is right, for several reasons:

• Extension methods, when used too much, are polluting IntelliSense. This could be extremely annoying when (1) the extension methods were created in a core namespace which is using-included in nearly every file of the project, and when (2) they are extending some very general interfaces or classes, such as object.

  An example of such pollution is NSubstitute. IntelliSense becomes nearly useless in a test project which includes NSubstitute, because there are so many items which are automatically suggested for everything, that the only way to know the members of a specific class or interface would be to go see its documentation, which is a bit disappointing.

• People who abuse extension methods could in many cases use elementary inheritance, or, in more esoteric situations, patterns such as the decorator pattern.

  A basic example I've seen recently. The code was dealing with geometrical shapes, and, among others, had to convert from meters to inches. The developer simply put two extension methods, ToInches and ToMeters for int, two other ones for double, etc. Instead, he could make an effort to make dedicated classes which encompass the value and the metric system being used, and allow conversions to other systems.

• Extension methods make unit testing more difficult than it needs to be, as would any public static method anyway, as opposed to an instance method of an object injected at runtime, with the possibility to replace it by a mock or a stub.

• By extending code which doesn't belong to you, you put yourself at risk of the author of the code adding the method which has the same name as your extension method, but which has a different implementation. This alone should encourage you to use extension methods sparingly, or at least limit yourself to interfaces only.

  As an example, a few years ago, a fellow developer told me a story. Their codebase had a magic method called public static string ToJson(this object x) which would, as you may imagine, return the JSON representation of an object. Nice and all, until one of the classes of a third party was updated with an addition of an instance ToJson method. It took about a week to the team to figure out why is the serialization rules suddenly changed for some of the objects, breaking the application which was consuming the service.

There are cases where extension methods are extremely valuable. LINQ is such case. But developers should be careful to limit themselves to cases similar to LINQ, instead of creating as many extension methods as they can.