I have recently started to make useful use of C# extension methods. The SO examples and the documentation suggest that they are only used for instance methods (i.e. with the this keyword). It is possible to use them (or another approach) with static/class methods?
(My particular requirement is converting Java code to C# where "most of the code" does not need editing. The Java instance methods (e.g. Java String.indexOf()) can be routed through an extension method calling C# string.IndexOf()). I would like to do the same for, say, Java Math.abs() => C# Math.Abs()).
SUMMARY No. The answers suggest it would be a reasonable thing to have but it's unlikely to happen soon. Workarounds will require editing creating new classes or something similar and may not be worth it.
You cannot create static extension methods - it's also something I've wished to be able to do!
You could create your own static classes with a standard suffix, i.e. MathJSyntax.abs(..) which would call Math.Abs(..)
C# 3.0 does not allow the creation of static extension methods, unfortunately. F# however does allow this, along with the much desired feature of extension properties.
The notation itself doesn't let you do it, the "this" class parameter expects an instance to the class to be passed in. If they intended to at least eventually add it, they wouldn't have written it like that.
So the short answer is nope, and never will be!
Related
I recently read an article about shadowing or hiding in programming (C++, C#, VB).
But I still don't get what's the reason of those? Why would we do something like that? I mean we can always call the real function if we want it to return the value, and not casting some class to it.
Well, I am not much a very very good at programming so I can't see the reason:)
Anyone can explain?
Thank you
In shadowing the child class has its own version of the method providing different implementation, the same method is also available in the base class.
Suppose you have class library being used by various modules in a project. There is a method which is being referenced other libraries. if we make a change in method it may break existing functionality. Hence we hide/shadow the method using new keyword. This way we are able achieve new functionality without breaking old functionality.
EDIT:
You can also find a great example on Eric Lippert's blog here.
This question already has answers here:
When do you use extension methods, ext. methods vs. inheritance?
(7 answers)
Closed 9 years ago.
I have been using C# extension methods for a while now and I find them to be really handy. However I am not really sure of what is the most ideal situation to use them, I feel at times I abuse them. When would you recommend the use of extension methods ?
IMO when either it's really an extension (and not a core/critical operation), or when it's a shortcut.
An example of an extension:
Often in sandbox applications (but it could also be used in real ones, of course) is extending IEnumerable with a Print method.
The print method shouldn't be there (that is: it shouldn't be a part of the IEnumerable class), but it's helping and making the syntax easier and cleaner. Also, you probably wouldn't want to ship a library with it as a part of that class.
An example of a shortcut:
Another thing I find myself often creating is an helper extension for objects with containers. Instead of calling Items.Add and similar, I just make an AddItem extension-method.
Something to consider is that it's just syntactic sugar, that is, it's for the you - the developer. So for .NET types and such use it when you think it's a good idea and will make things cleaner.
When it comes to "Should this method be an extension or a member?" see the first sentence in this answer, and also look here & here for more information.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In what circumstances (usage scenarios) would you choose to write an extension rather than sub-classing an object ?
< full disclosure : I am not an MS employee; I do not know Mitsu Furota personally; I do know the author of the open-source Componax library mentioned here, but I have no business dealings with him whatsoever; I am not creating, or planning to create any commercial product using extensions : in sum : this post is from pure intellectal curiousity related to my trying to (continually) become aware of "best practices" >
I find the idea of extension methods "cool," and obviously you can do "far-out" things with them as in the many examples you can in Mitsu Furota's (MS) blog postslink text.
A personal friend wrote the open-source Componax librarylink text, and there's some remarkable facilities in there; but he is in complete command of his small company with total control over code guidelines, and every line of code "passes through his hands."
While this is speculation on my part : I think/guess other issues might come into play in a medium-to-large software team situation re use of Extensions.
Looking at MS's guidelines at link text, you find :
In general, you will probably be
calling extension methods far more
often than implementing your own. ...
In general, we recommend that you
implement extension methods sparingly
and only when you have to. Whenever
possible, client code that must extend
an existing type should do so by
creating a new type derived from the
existing type. For more information,
see Inheritance (C# Programming
Guide). ... When the compiler
encounters a method invocation, it
first looks for a match in the type's
instance methods. If no match is
found, it will search for any
extension methods that are defined for
the type, and bind to the first
extension method that it finds.
And at Ms's link text :
Extension methods present no specific
security vulnerabilities. They can
never be used to impersonate existing
methods on a type, because all name
collisions are resolved in favor of
the instance or static method defined
by the type itself. Extension methods
cannot access any private data in the
extended class.
Factors that seem obvious to me would include :
I assume you would not write an extension unless you expected it be used very generally and very frequently. On the other hand : couldn't you say the same thing about sub-classing ?
Knowing we can compile them into a seperate dll, and add the compiled dll, and reference it, and then use the extensions : is "cool," but does that "balance out" the cost inherent in the compiler first having to check to see if instance methods are defined as described above. Or the cost, in case of a "name clash," of using the Static invocation methods to make sure your extension is invoked rather than the instance definition ?
How frequent use of Extensions would affect run-time performance or memory use : I have no idea.
So, I'd appreciate your thoughts, or knowing about how/when you do, or don't do, use Extensions, compared to sub-classing.
thanks, Bill
My greatest usage for them is to extend closed-off 3rd party APIs.
Most of the time, when a software developer is offering an API on Windows these days, they are leaning more and more toward .NET for that extensibility. I like to do this because I prefer to depend on my own methods that I can modify in the future and serve as a global entry point to their API, in the case that they change it.
Previously, when having to do this, and I couldn't inherit the API object because it was sealed or something, I would rely on the Adapter pattern to make my own classes that wrapped up their objects. This is a functional, but rather inelegant solution. Extension methods give you a beautiful way to add more functionality to something that you don't control.
Many other peoples' greatest usage for them is LINQ!
LINQ would not be possible without the extension methods provided to IEnumerable.
The reason why people love them is because they make code more readable.
I have noticed another MAJOR usage of extension methods (myself included) is to make code more readable, and make it appear as if the code to do something belongs where it is supposed to. It also gets rid of the dreaded "Util" static-god-class that I have seen many times over. What looks better... Util.DecimalToFraction(decimal value); or value.ToFraction();? If you're like me, the latter.
Finally, there are those who deem the "static method" as EVIL!
Many 'good programmers' will tell you that you should try to avoid static methods, especially those who use extensive unit testing. Static methods are difficult to test in some cases, but they are not evil if used properly. While extension methods ARE static... they don't look or act like it. This allows you to get those static methods out of your classes, and onto the objects that they really should be attached to.
Regarding performance..
Extension methods are no different than calling a static method, passing the object being extended as a parameter... because that is what the compiler turns it into. The great thing about that is that your code looks clean, it does what you want, and the compiler handles the dirty work for you.
I use extension methods as a way to improve the functionality for classes without increasing the complexity of the class. You can keep your classes simple, and then add your repetitive work later on as an extension.
The Min() and Max() extension methods are great examples of this. You could just as easily declare a private method that would calculate these, but an extension method provides better readability, makes the functionality available to your entire project, and didn't require making an array any more complex of an object.
Taking the sub-classing approach vs. extension methods requires a couple of things to be true
The type must be extendable (not-sealed)
All places the type is created must support a factory pattern of sorts or the other code will just create the base type.
Adding an extension method requires really nothing other than using a C# 3.0+ compiler.
But most importantly, an inheritance hierarchy should represent an is-a relationship. I don't feel that adding 1 or 2 new methods / behaviors to a class truly expressing this type of relationship. It is instead augmenting existing behavior. A wrapper class or extension method much better fits the scenario.
In some cases you can't use a subclass: string for instance is sealed. You can however still add extension methods.
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.