|
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."
|
|
|
|
|
|
What is extensively?
I have a small set of extension methods, but I use them a lot. On sealed classes.
Examples:
DBInt("columnName") - returns int value of column in a datarow, and cleans up DBNull issues.
HiddenCreditCard(CC Number String) - returns CC Number showing only first and last four digits, with asters in between.
|
|
|
|
|
I use extension methods somewhat. I'm slowly building a suite of useful methods. There is also the site extensionmethod.net too.
I keep the extension methods in a core library, but the methods are declared in the namespace of the class I'm targeting. That way, when I reference the core library all the extension methods are available without superfluous using statements.
Be careful, there is an ongoing debate on the internets about whether they're a good thing or bad thing. I would say, use sparingly, and note that an extension method is probably sign-posting a limitation in your design.
As well as other suggestions, I've used them to clean up a messy code base I've inherited. In this code base there were a number of inappropriate methods attached to a static globals class. Side-stepping the whole issue of a statics globals class, the methods attached to it were moved onto extension methods. Not a perfect solution, but migrating to extension methods helped me nudge the legacy code in the right direction.
|
|
|
|
|
|
Now for the trivia question - which episode (or episodes) did the pics come from?
My guess is Amok Time.
Marc
|
|
|
|
|
Pretty sure only the Doc would be decorating a Christmas tree.
|
|
|
|
|
Starting 28 November, I will be working in Stuttgart for the US Army.
NO MORE CODING! I won't have to touch any web servers or nuffin like that anymore. (As far as I know)
Nothing but SA/DBA things to do.
|
|
|
|