The practical use of delegates

[=?Utf-8?B?T2xkQ2FEb2c=?=]

My question is regarding the use of delegates in C#. I see how .Net uses
delegates to wire event handlers to events. It’s an object created by a
single line of code by the system and that makes perfect sense to me. I
understand that there is a lot of code underneath that the system has created
that makes it all work, thereby making it pretty efficient for the programmer.

Outside of the use of delegates to wire event handlers, you can create your
own delegates to make a call to a method, which according to some, makes
delegates perfect for implementing callbacks. My question is this:

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance methods).
Are delegates good all the time, some of the time, or when? Am I missing
something? Why are so many so high on using delegates as much as they can?
Is there a security issue that makes delegates better than a direct call?

I just don’t have enough experience yet to figure this one out yet. Any
help will be appreciated. Thanks in advance for your help.

--
Scott

[Nicholas Paldino [.NET/C# MVP]]

Scott,

Well, the callback is a perfect example. You might know the method that
needs to be called at a certain point in the procedure, but that would tie
that code to that specific procedure, and not make the code very flexible.

Great examples of this are callbacks in Sockets when data is read, data
base connections when commands are executed, etc, etc. Delegates are a
great way to indicate the action that should be taken when an operation is
complete.

Granted, you could use interface implementations (create a specialized
interface which has a method with the signature you need for the callback)
but that can be a little bit of a hassle if you want to keep your code more
clean/concise (as the implementation would typically be in another class,
but then you have to have that other class call back into the calling class
to do the work). This is one of the things I didn't like in the early days
of Java (we are talking 10 years ago).

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"OldCaDog" <sb*******@comm unity.nospamwro te in message
news:62******** *************** ***********@mic rosoft.com...

My question is regarding the use of delegates in C#. I see how .Net uses
delegates to wire event handlers to events. It's an object created by a
single line of code by the system and that makes perfect sense to me. I
understand that there is a lot of code underneath that the system has
created
that makes it all work, thereby making it pretty efficient for the
programmer.

Outside of the use of delegates to wire event handlers, you can create
your
own delegates to make a call to a method, which according to some, makes
delegates perfect for implementing callbacks. My question is this:

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance
methods).
Are delegates good all the time, some of the time, or when? Am I missing
something? Why are so many so high on using delegates as much as they
can?
Is there a security issue that makes delegates better than a direct call?

I just don't have enough experience yet to figure this one out yet. Any
help will be appreciated. Thanks in advance for your help.

--
Scott

[sloan]

One way to consider the use of delegates is like this
"Delegates are kinda Microsoft's "built in" Observer Pattern".

See
http://www.dofactory.com/Patterns/PatternObserver.aspx

Instead of doing the Observer pattern , with an interface like IObserver,
you can use delegates to handle this.
So anywhere that the Observer pattern would make sense, you can use
delegates.


"OldCaDog" <sb*******@comm unity.nospamwro te in message
news:62******** *************** ***********@mic rosoft.com...

My question is regarding the use of delegates in C#. I see how .Net uses
delegates to wire event handlers to events. It's an object created by a
single line of code by the system and that makes perfect sense to me. I
understand that there is a lot of code underneath that the system has
created
that makes it all work, thereby making it pretty efficient for the
programmer.

Outside of the use of delegates to wire event handlers, you can create
your
own delegates to make a call to a method, which according to some, makes
delegates perfect for implementing callbacks. My question is this:

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance
methods).
Are delegates good all the time, some of the time, or when? Am I missing
something? Why are so many so high on using delegates as much as they
can?
Is there a security issue that makes delegates better than a direct call?

I just don't have enough experience yet to figure this one out yet. Any
help will be appreciated. Thanks in advance for your help.

--
Scott

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

"OldCaDog" <sb*******@comm unity.nospamwro te in message
news:62******** *************** ***********@mic rosoft.com...

My question is regarding the use of delegates in C#. I see how .Net uses
delegates to wire event handlers to events. It's an object created by a
single line of code by the system and that makes perfect sense to me. I
understand that there is a lot of code underneath that the system has
created
that makes it all work, thereby making it pretty efficient for the
programmer.

Outside of the use of delegates to wire event handlers, you can create
your
own delegates to make a call to a method, which according to some, makes
delegates perfect for implementing callbacks. My question is this:

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance
methods).

You are right, but what if you do not know the actual method you will need
to call?
A callback is an excellent example of this.

In this case you need a feature that let you dynamically select which method
to call. This feature are the delegates.

[Jon Skeet [C# MVP]]

OldCaDog <sb*******@comm unity.nospamwro te:

<snip>

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance methods).

And when you know exactly what to call at the point you want to make
the call, you might as well call the method directly.

Delegates are specifically for situations where you want the action to
take place at one point of the code, but you want to be able to control
what happens from another point of code.

In C# 1, delegates are relatively rarely used outside event handlers
and callbacks.

In C# 2 there are more uses (e.g. List.ConvertAll etc) and various
language enhancements make them easier to use.

In C# 3 there's *far* more scope to use delegates due to LINQ etc - and
lambda expressions make them really, really concise.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?Utf-8?B?T2xkQ2FEb2c=?=]

Thank you all for taking the time to comment, I really appreciate it! You've
all given me much more to consider and investigate, thanks again.
--
Scott
"Jon Skeet [C# MVP]" wrote:

OldCaDog <sb*******@comm unity.nospamwro te:

<snip>

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance methods).

And when you know exactly what to call at the point you want to make
the call, you might as well call the method directly.

Delegates are specifically for situations where you want the action to
take place at one point of the code, but you want to be able to control
what happens from another point of code.

In C# 1, delegates are relatively rarely used outside event handlers
and callbacks.

In C# 2 there are more uses (e.g. List.ConvertAll etc) and various
language enhancements make them easier to use.

In C# 3 there's *far* more scope to use delegates due to LINQ etc - and
lambda expressions make them really, really concise.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael Starberg]

"OldCaDog" <sb*******@comm unity.nospamwro te in message
news:62******** *************** ***********@mic rosoft.com...

In a lot situations, I can create less code by calling that function or
method directly rather than using delegates (for static or instance
methods).
Are delegates good all the time, some of the time, or when?

This thread is mostly about when to use delegates.
Let me turn it on its head, becuase you seem to have heard
that delegates are good, and that you should use them.

But I'd like to stress this, that has not yet to mentioned yet in this
thread.
But you seem to have figured it out. :)

- If you know the method (on a known instance) of a specific class to
call...
- You should call it directly!

By using a delegate to call a known method,
you are just not only engaging in total overkill, it is bad code!
As your code would suggest the call is dynamic and could change,
when it is not.

String.Format(" Only exception is if you really hate
your {0} maintainers {1}, "future", ", that might be yourself 2 years
later");

..NET Is Not Java :)
- Michael Starberg