Why use a delegate

[garyusenet]

Following on from a previous thread in which types were discussed. I
was interested to read more about these differeent types. I started by
trying to learn about the delegate type, of which I had never seen
before.

I have so far managed to find out that a Delegate type is simmilar to a
function pointer, but the main difference is that it is type safe. I
haven't come accross the term function pointer before, but from what I
can gather the the delegate merely lets you call a static method, or
call an instance method. To facilitate this it takes either a static
method, or an object and instantiated method as it's arguments.

I can't see what it's actual use is?

Why not just call the method directly?

Thanks,

Gary-

 

[Oliver Sturm]

Hello,

Why not just call the method directly?

The typical reason for that is that from a particular piece of code, it is
not known what that method is going to be. A traditional example for this
is a simple sorting algorithm - that sorting algorithm needs to compare
values, and so it uses a function pointer or a delegate to do the
comparing, which makes the sorting algorithm very universal in its
application.

This kind of implementation can be found in .NET's List<T>.Sort() method,
as one of its overloads takes a delegate of type Comparison<T> as a
parameter. This MSDN page has an example of using that method:

http://msdn2.microsoft.com/en-us/library/w56d4y5z.aspx

Another thing worth mentioning is that the whole event system is based on
delegates. So every time you write some code in an event handler on a
form, you're basically creating a delegate method that is being used by
the Windows Forms library (for example) - obviously the Windows Forms
developers didn't know you were going to write that particular piece of
code, so they used delegates as an "extensibility" feature in their library.


Oliver Sturm

 

[Samuel R. Neff]

It's good to think of Delegates as basically how Events work. Of
course they can be used for callbacks and other things (another poster
mentioned sorting an array) but for those types of callback Interfaces
are much cleaner and self documenting.

HTH,

Sam

 

[Jon Skeet [C# MVP]]

It's good to think of Delegates as basically how Events work. Of
course they can be used for callbacks and other things (another poster
mentioned sorting an array) but for those types of callback Interfaces
are much cleaner and self documenting.

I disagree with that - particularly when you consider anonymous
methods. Something like List<T>.FindAll works very neatly with
anonymous methods, keeping the predicate cleanly with the code using
it. (Not so good if you're using the same kind of predicate in multiple
places, but that's a different matter.)

To do the same thing with an interface requires an extra class to be
used just for the sake of matching things (or bolting it onto an
existing class, which is usually a bit of a hack) *and* it doesn't
provide the access to other data (local variables etc) that anonymous
methods do.

They're equivalent in terms of what you *can* do after some effort, but
given the choice between a single-method interface and a delegate, I'd
usually say the delegate is an easier thing to work with.

(The recent RC1 release of Groovy allows a closure to automatically
implement a single-method interface. I've already found that
considerably neater than "properly" implementing interfaces.)