Why does Microsoft use extension methods for classes that it creates; instead of just adding the methods to the classes, or creating child classes?
-
1Answering this in general would be very difficult. Please give some specific examples. – Jon Skeet Aug 05 '11 at 14:13
-
I mentioned this below but, the `IgnoreRoute()` method for the `RouteCollection` collection – Josh Russo Aug 05 '11 at 14:21
5 Answers
There are a number of reason Microsoft did this. The two biggest being:
Extension methods apply to interfaces, not just classes. Had Microsoft simply added the Linq methods directly to IEnumerable, it would have required every concrete implementation of that interface to implement those methods as well. By making them extension methods, written in terms of the existing IEnumerable<> behavior, every IEnumerable<> class gets them automatically.
For the 3.0 and 3.5 Frameworks, the core System.dll is the 2.0 library. Everything new in 3.0 ad 3.5 was added on top of that, in System.Core or other related libraries. The only way to get, for example, a new method in the List<> class that exists in 3.5 but not in 2.0 is to make in an extension method available in a 3.5 library.

- 28,070
- 4
- 86
- 117
-
also eric lippert [has blogged about this](http://blogs.msdn.com/b/ericlippert/archive/2011/06/30/following-the-pattern.aspx) – bottlenecked Aug 05 '11 at 15:21
IgnoreRoute()
on RouteCollection
is an extension method because it is intended for use with the MVC framework, rather than a core ASP.NET application. My guess would be that they didn't want to pollute the RouteCollection
class with methods that non-MVC applications wouldn't need, while still allowing MVC applications to make use of the class.
I'm not sure this approach necessarily make sense (since, for example, they could have just created a child class); for more general reasons that extension methods might be used, others have answered nicely.

- 48,024
- 5
- 125
- 132
-
MVC is another case similar to the .NET 2 -> 3 enhancements. Most of the base classes are identical to the non-MVC ASP.NET, but the MVC Framework wants those same classes to "work better" with the MVC features. Deriving a child class would work technically, but be sortof "philosophically incorrect" -- there aren't really two RouteCollection classes; there's one class, and if you "upgrade" to the MVC Framework, it gets smarter. – Michael Edenfield Aug 05 '11 at 16:10
This is an example of the Non-Virtual Interface pattern (similar to Template Method). This is a pattern used in languages with multiple (implementation) inheritance, and the way to do it in C# is to use extension methods.
The basic idea is that you have only non-virtual and pure-virtual (abstract) methods. The implementor of the interface (or inheritor of the class/mixin, in languages with multiple inheritance), implements a small method or set of methods (in this case, GetEnumerator), and in return gets a whole slew of methods that depend on that one abstract method (like Select, Where, Aggregate, etc.)
As Michael Edenfield said in his answer, if we want to implmeent this pattern and we want IEnumerable to be an interface, we need to use extension methods. And making IEnumerable into an abstract class would be bad because its supposed to be a very low-cost, basic interface that should be put on pretty much any collection - implementing IEnumerable should not require rethinking a class hierarchy, it should be almost "for free".
I think the main reason is that it's very easy to extend such methods. For example, if you Linq extension methods you can easily write yout own set of extension methods (maybe foreach or some specific filter) which will work greate with microsoft methods: mylist.Where(...).MyFilter(...).Select(...)

- 877
- 2
- 8
- 22
My two cents:
because extension methods were added only in later versions of the .NET framework, they already had .NET Framework 1, 1.1, 2.0 and newer then at some point they added extension methods so they have used them to enrich the feature set on top of existing classes.

- 43,984
- 10
- 98
- 147
-
1Why this is a reason? Lets take a look in Linq extension methods. In order to use linq methods you should use .Net framework 3.5 or later, right? You can't keep using .Net 1, 1.1 or 2.0 and use linq methods anyway. So you have to move to .Net 3.5 and even if linq was implemented in classes (like List etc.) it could still prefectly work in client code like: mylist.Where().Select()... – Oleg Ignatov Jan 29 '16 at 07:37