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:
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.
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.
Related
The Extension Methods documentation says:
For a class library that you implemented, you shouldn't use extension
methods to avoid incrementing the version number of an assembly.
So why has the .NET team used them extensively in Enumerable and Queryable?
In search of a reason I checked out my copy of C# In Depth, where I came away with a feeling that extension methods are used because:
You can chain them together in a readable way
You can bring them in and out of scope
Is this correct or are the .NET team flying in the face of their own documentation? Are there other reasons that justify their use?
That's not the entire sentence. What is actually written is this:
For a class library that you implemented, you shouldn't use extension methods to avoid incrementing the version number of an assembly. If you want to add significant functionality to a library for which you own the source code, you should follow the standard .NET Framework guidelines for assembly versioning.
(emphasis added)
What this means is that you should avoid just adding extension methods to a class when you're adding large amounts of functionality, just for the sake of not incrementing the assembly version. If you're going to introduce large amounts of new functionality, you should really do it in a new version of that assembly.
It's because LINQ works on IEnumerable, not any specific implementation of a collection. If they were part of the definition of IEnumerable, you would have to implement your own methods, and it would needlessly bloat the interface. By putting LINQ into extension methods, you can implement IEnumerable on any class you create yourself, and the existing LINQ methods will work on it.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Extension Methods vs Static Utility Class
I am building an API of general functions which perform actions based upon objects in .NET. For example; I have created a function that checks a string to see if it is an email address.
I could either have:
static bool IsEmailAddress(string text)
{
return IsMail(text);
}
or I could create an extension method that would be used like so:
string text = "HelloWorld#Email.com";
if (text.IsEmailAddress())
{
}
which is more suitable, or do you think since this is a general purpose library, I could technically implement it both ways and allow the developer to decide which is best for them?
Creating an extension method means that it will automatically show up during intellisense when a user uses that type. You have to be carefull not adding a lot of noise to the list of methods developers browse (especially when creating a reusable framework). For instance, when those methods are just usable in a certain context, you are probably better of using 'normal' static methods. Especially when implementing extension methods for general types such as string.
Take for instance an ToXml(this string) extension method, or an ToInt(this string) extension methods. Although it seems pretty convenient to have these extension methods, converting text to XML is not something you will do throughout the application and it would be as easy to have do XmlHelper.ToXml(someString).
There is only one thing worse, and that is adding an extension method on object.
If you're writing an reusable framework, the book Framework-Design-Guidelines by Krzysztof Cwalina is an absolute must read.
I prefer Extension Method, because your code is elegant, and you can define an extension method on a sealed class of the framework.
The question is which .NET Framework will you target? If < 3.5 then extension methods are not available. Otherwise, why would you create a new class?
An extension method is automatically part of a static class. This means that the consumer can use either the extension methods or call the static method from the class if she wants it. I use extension methods as much as I can, they are easier to discover if they're put in the proper namespace.
Extension methods allow developers to not be aware exactly what the helper class is called and where it is located, not to mention the very fact of its existence. Do note, that you still need to put their namespace in using clause - perhaps place them in some common, top-level namespace for your application.
Should extension methods only be used on classes whose code you don't have access to?
I'm struggling to come up with a reason to have extension methods versus making it partial and adding the classes in an external file.
My specific scenario is as follows: I have classes that represent entities in a database via EF. I'm debating making the classes it renders partial and adding my own methods. Are extension methods a more valid alternative approach or are they not intended to be used when you have access to the code of the class you are extending?
The canonical counter-example is extension methods on an interface, as even if you control the source, there is no implementation. See: Linq.
But, yes, generally speaking, if you control the source of the concrete class, it is not unreasonable to expect to add the functionality to the class directly rather than using an extension method, if it makes sense for the functionality to actually be part of the class instance.
On the other hand, and coming back to your situation, you might consider neither approach. Your entities are data models, I would not add methods to those models, but rather encapsulate that functionality elsewhere. Those models exist to encapsulate your data, logic that might operate with or against that data might be better served in a different unit. But that really depends upon what your methods are doing, and also assuming they're not something like a trivial wrapper over one or more properties, for example.
Apart from the ability to provide extensions to interfaces, I use extension methods to add 'members' to a class that work using only the class' public interface. So if a method needs access to a private/protected member, it will become a class member, if not an extension method. This keeps the classes themselves small and focused...
No.
You may have a class that works fine in ninety percent of your projects. By adding an extension method you don't 'pollute' the original class but can still leverage it in the other ten percent of your projects.
Should extension methods only be used on classes whose code you don't have a access to?
Not necessarily. There are situations where extension methods can still help. I recently had an issue with the xml serializer where it could serialize an object that had a method that made use of a linq / lamba expression. Moving the method to an extension method resolved that. I like to use extension methods on DTOs also.
You might want to look at How Non-Member Functions Improve Encapsulation. There are some C++ specifics, but main idea applies to other OO languages as well. In short: the less methods you have in a class the easier it is to understand who and how changes private class state.
I'd like to override the Serialize methods of the ASP.NET JavaScriptSerializer class. Nothing too fancy, I just want to do some additional post processing to the serialized string returned from .NET.
Unfortunately, none of the methods on this class are declared virtual and the class itself does not derive from an interface or abstract class (seems like a strange oversight given how many of the core .NET Framework classes are designed for extensibility).
Based on some reading I've done on the subject, it appears that I have a couple of options to choose from.
Create an extension method. I'm not a huge fan of this option, since it involves creating a new method (compiler won't allow using the same name/signature twice) that class consumers would need to be aware of.
Derive a new class from JavaScriptSerializer that has the exact same signature. Since JavaScriptSerializer has no virtual methods, I would use the "new" keyword in each method/property declaration in order to perform method hiding. I think this option is considered a decorator pattern?
Create a new interface called IJavaScriptSerializer that would have the same signature as JavaScriptSerializer. Remove all references in my code to JavaScriptSerializer and replace with references to the newly created interface.
I'd love to hear about additional approaches and the pros/cons of each approach.
Thanks for taking the time to read.
You're misunderstanding the Decorator Pattern, which refers to an object that inherits a class and wraps another instance of that class. (This is very common for streams). In your case, it's inapplicable.
I would recommend that you make your own replacement (or wrapper, whichever you need) for the JavaScriptSerializer class, without trying to have an identical API. If you need to be able to swap implementations, I would make an interface or base class with the core methods, and have two concrete implementations of it, one wrapping the original and one adding your post-processing.
In general, when designing classes, you should design to meet your needs, not to copy the .Net Framework's built-in classes.
Go to http://json.org and d/l one of the several classes that have source code, for JSON serialization.
Then, put in your post-processing, compile and use in your project.
Ideally, at this point I would create an extension method so I can just do this:
List<MyObject> s = fillObject();
return s.ToJSON();
I was wondering what is the design motive behind extension methods in C#
It allows you to create new functionality to an existing code base without editing the original code.
http://weblogs.asp.net/scottgu/archive/2007/03/13/new-orcas-language-feature-extension-methods.aspx
"Extension methods allow developers to add new methods to the public contract of an existing CLR type, without having to sub-class it or recompile the original type. Extension Methods help blend the flexibility of "duck typing" support popular within dynamic languages today with the performance and compile-time validation of strongly-typed languages.
Extension Methods enable a variety of useful scenarios, and help make possible the really powerful LINQ query framework that is being introduced with .NET as part of the "Orcas" release."
The primary reason for their existence is being able to somehow add features to a type without inheriting from it.
This was required to provide Where, Select, ... methods for use in LINQ for collections that didn't have one.
It provides multiple inheritance via the back door.
It languages such as C++, which support inheriting from many classes, extension methods aren't required. However multiple inheritance has lots of problems with it, and so modern languages have dropped it. However extension methods are a use-case where multiple inheritance is useful. Rather than re-introduce multiple inheritance though, the C# designers created extension methods (which is a very neat solution to the problem).
Quite often we end up writing for ourselves usefull little utility static classes that perform a common function on a type. I know there have been a number of times I wished I could simply inherit a class to add a feature but that class is sealed. I'm glad though they were sealed, unwarranted inheriting is a bad thing.
Extension methods make code look more intuitive by allowing those static methods to appear to be new instance methods of the type.
They also have the advantage of not polluting the actual member namespace of the type and allowing you to opt into them by means of the using keyword.
The existence of Extension Methods is very likely due to the need for Microsoft to add functionality to IEnumerable without changing the interface. If they added methods to the interface, then every existing implementation of IEnumerable (including Microsoft's) would no longer compile.
The alternative to changing IEnumerable is to create a utility class (called Enumerable) which has methods that perform transformations on instances of IEnumerable. This works, except the user experience is not the same as calling a method from an existing IEnumerable instance. For instance, compare the following equivalent statements.
IEnumerable<string> strings = myIntList.Select(num => num.ToString())
.Where(num => num.StartsWith('T'));
IEnumerable<string> strings =
Enumerable.Where(
Enumerable.Select(myIntList, num => num.ToString()),
num => num.StartsWith('T'));
To achieve the best of both worlds, the C# compiler team added support for extension methods, allowing the creation of the Enumerable class with special syntax and maintaining the same user experience of having added the methods to IEnumerable to begin with.