简体   繁体   中英

Why does Microsoft use extension methods for their own classes?

Why does Microsoft use extension methods for classes that it creates; instead of just adding the methods to the classes, or creating child classes?

There are a number of reason Microsoft did this. The two biggest being:

  1. 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.

  2. 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.

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.

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(...)

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM