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.