Using delegate Types vs methods

Question

I see increasing use of the delegate types offered in the System namespace (Action<T>; Predicate<T> etc). As these are delegates, my understanding is that they should be used where we have traditionally used delegates in the past (asynchronous calls; starting threads, event handling etc). Is it just preference or is it considered practice to use these delegate types in scenarios such as the below; rather than using calls to methods we have declared (or anonymous methods):

public void MyMethod()
{
      Action<string> action = delegate(string userName
      {
            try
            {
               XmlDocument profile = DataHelper.GetProfile(userName);
               UpdateMember(profile);
            }
            catch (Exception exception)
            {
               if (_log.IsErrorEnabled) _log.ErrorFormat(exception.Message);
               throw (exception);
            }
      };

      GetUsers().ForEach(action);
}

At first, I found the code less intuitive to follow than using declared or anonymous methods. I am starting to code this way, and wonder what the view are in this regard. The example above is all within a method. Is this delegate overuse?

This code might be behind the right door: http://www.osnews.com/story/19266/WTFs_m If functional programming suits you, consider F# instead. — Hans Passant, Jun 12 '10 at 15:24
Thanks for your answer (and excellent link). Yes! I agree with the fact that there is a WTF, when you first see something coded this way. But as with anything new there is always a WTF moment, until you take the time to look at it and figure it out. After this, you recognise the pattern in the future and there is no longer a WTF. If there is nothing wrong with this way way of coding (such as performance); can this might just be considered a 'style' of coding. — Grant Sutcliffe, Jun 12 '10 at 16:01
possible duplicate of [C#, Action/Func vs Methods, what's the point?](http://stackoverflow.com/questions/7630538/c-action-func-vs-methods-whats-the-point) — nawfal, Dec 20 '13 at 06:23

score 4 · Accepted Answer · edited Mar 18 '21 at 07:13

4

For a simple foreach loop, I would prefer the normal language construct - see this blog post for Eric Lippert's view. I think the use of a delegate here is somewhat gratuitous.

In other cases - particularly with LINQ - it makes a lot of sense.

Delegates are a nice way of allowing specialization without the overhead of declaring and implementing an interface or deriving from a type in order to override methods... but everything in moderation, of course. If you've got several methods to implement (and you really want to specify behaviour for all of them) then an interface makes more sense. If you're genuinely creating a specialized type then deriving and overriding make sense. If you're wanting a strategy pattern, however, then delegates work very neatly.

edited Mar 18 '21 at 07:13

Glorfindel

21,988
13
81
109

answered Jun 12 '10 at 14:06

Jon Skeet

1,421,763
867
9,128
9,194

Thanks for your answer and Link. I presume that with LINQ, you mean because you might have a number or statements (filters etc), to shape the data contained in the list - that will then be operated on. This being distinct to just carrying out some procedural method calls, as in the example in my question. – Grant Sutcliffe Jun 12 '10 at 16:09
@Grant: I mean that LINQ uses delegates (or expression trees) all over the place. There's no point in writing the filtering logic of Where, the projecting logic of Select etc all over the place - whereas in the case of ForEach vs foreach, you're not really gaining anything by using a delegate. – Jon Skeet Jun 12 '10 at 16:35

Using delegate Types vs methods

1 Answers1