What is the motivation behind "Use Extension Methods Sparingly?"

Question

I find them a very natural way to extend existing classes, especially when you just need to "spot-weld" some functionality onto an existing class.

Microsoft says, "In general, we recommend that you implement extension methods sparingly and only when you have to." And yet extension methods form the foundation of Linq; in fact, Linq was the reason extension methods were created.

Are there specific design criteria where using extension methods are perferred over inheritance or composition? Under what criteria are they discouraged?

Answer 1

We show proposed new language features (at least the ones that have a halfway decent chance of seeing the light of day) to the C# MVPs for early feedback. Some feedback we get very often on many features is "well I would use this feature judiciously and in accordance with the design principles of the feature, but my goofball coworkers are going to go crazy nuts with this thing and write up a mass of unmaintainable, non-understandable code that I'm going to get stuck with debugging for the next ten years, so as much as I want it, please never implement this feature!"

Though I am exaggerating somewhat for comedic effect, this is something we take very seriously; we want the design of new features to encourage their use but discourage their misuse.

We worried that extension methods would be used to, for example, indiscriminantly extend "object" arbitrarily and thereby create big balls of loosely typed mud that would be hard to understand, debug and maintain.

I'm personally in particular concerned about "cute" extension methods that you see in "fluent" programming. Stuff like

6.Times(x=>Print("hello"));

Yuck. "for" loops are universally understandable and idiomatic in C#; don't get cute.

Answer 2

The problem is that Extension methods aren't necessarily clear.

When you see something like this in code:

 myObject.Foo();

The natural instinct is that Foo() is a method defined on myObject's class, or a parent class of myObject's class.

With Extension methods, that's just not true. The method could be defined nearly ANYWHERE, for nearly any type (you can define an extension method on System.Object, although it's a bad idea...). This really increases the maintenance cost of your code, since it reduces discoverability.

Any time you add code that is non-obvious, or even reduces the "obviousness" of the implementation, there is a cost involved in terms of long term maintainability.