|
As OG pointed out when adding functionality to sealed class then yes, but otherwise I consider between extension methods and inheritance. Mainly because I often need more functionality than just a method and perhaps even new instance variables.
But yes I use them when I see fit.
|
|
|
|
|
I'm sure the OP means extension methods for native .Net objects, such as string , Type , DateTime , etc.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yep, that's what I understood.
|
|
|
|
|
I use them a lot to encapsulate the business meaning of a specific IEnumerable<t> Where clause. Makes code much more readable.
|
|
|
|
|
My most recent ones calculate business chart trend line values from either an IEnumerable<double> or a IEnumerable<T> using the named property.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
this is a good one..
diligent hands rule....
|
|
|
|
|
Yes I do. I use the ones MS created, I use them to enhance built-in types and I use them to enhance my own types.
Only when it makes sense, of course
|
|
|
|
|
I mostly use them for things that can't have methods defined on them directly, interfaces and enums.
|
|
|
|
|
For some reason I never thought of writing them for enums, though I use them for interfaces all the time. Can you give an example where an extension method for an enum would be useful? Can't think of any myself off hand.
|
|
|
|
|
Well it depends on what that enum is about, it's not always useful. I've used it for example to give an enum ConditionCode { etc the fake-methods Invert and SwapOperands .
|
|
|
|
|
|
public static bool Yes<T>(this T foo) {return true;}
Marc
|
|
|
|
|
Samhain (Halloween) is still fifteen days away, but you got my vote on this one, anyhow.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
very inspirational
diligent hands rule....
|
|
|
|
|
Marc Clifton wrote: public static bool Yes<T>(this T foo) {return true;} That looks suspiciously like an advert for Ty-phoo tea!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I use them whenever they make the code clearer & more concise, which is often.
Intensively? Probably not.
Extensively? Maybe.
|
|
|
|
|
Extensively, yes. Intensively, no.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
We use them in order to have POCO's and then attach extension methods to them to give them some mojo.
cheers
Chris Maunder
|
|
|
|
|
Why not implement in the object themselves and keep them contained and organized? Is there anything preventing the code to be where it belongs?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Separation of concerns, mostly.
cheers
Chris Maunder
|
|
|
|
|
Extensively sounds funny to me. Unless you are creating a framework of extension methods for built-in or third party types, using it intensively may indicate you're doing something wrong with your code.
They have a purpose, be sure you understand it before using it everywhere. It may create unorganized, hard to maintain code.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Yes, quite a bit. I love the extension method concept. Now if they could just implement "extension properties". Yes, I know you can use extension methods to pseudo-implement properties, but a full-blown extension property implementation would be sweet...
|
|
|
|
|
The core products for the company I work for are mainly COM based libraries. I've written .Net libraries of extension methods that help hide the COM ugliness and provide a more .Net friendly interface.
|
|
|
|
|
I have a .NET Core based Redis Client that I've been working on for a while that heavily uses extension methods. The 'client' just knows how to send a command and receive a response.
All the Redis commands are implemented as extension methods on the 'client'. So as static class for the Key Commands, another for the Hash Commands, ...
in Redis Client
public Task SendAsync(string command, params object[] parameters)
{
return SendAsync(command, (IEnumerable<object>)parameters);
}
public async Task SendAsync(string command, IEnumerable<object> parameters = null)
{
await EnsureConnected().ConfigureAwait(false);
await _commandWriter.WriteRedisCommandAsync(command, parameters).ConfigureAwait(false);
}
in HashCommands
public static Task SendHGetAsync(this RedisClient client, string key, string field)
{
if (string.IsNullOrWhiteSpace(key))
throw new ArgumentNullException(nameof(key));
if (string.IsNullOrWhiteSpace(field))
throw new ArgumentNullException(nameof(field));
return client.SendAsync("HGet", key, field);
}
Each commands are small and trivial. The core client has no tricky dependencies on the commands. Classic Open for Extension but Closed for Modification.
What has been delaying me is the number of tests to test all the commands, plus an update to the latest .NET Core bits.
Another great thing about Extension Methods is the ability to extend 3rd party libraries.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|