Why does trying to understand delegates feel like trying to understand the nature of the universe?

Question

I've read two books, tons of examples. They still make next to no sense to me. I could probably write some code that uses delegates, but I have no idea why. Am I the only one with this problem, or am I just an idiot? If anyone can actually explain to me when, where, and why I would actually use a delegate, I'll love you forever.

Answer 1

As other people have mentioned delegates are handy for callbacks. They're useful for a whole load of other things too. For example in a game I've been working on recently bullets do different things when they hit (some do damage, some actually increase the health of the person they hit, some do no damage but poison the target and so on). The classical OOP way to do this would be a base bullet class and a load of subclasses

Bullet     DamageBullet     HealBullet     PoisonBullet     DoSomethingElseBullet     PoisonAndThenHealBullet     FooAndBarBullet     .... 

With this pattern, I have to define a new subclass every time I want some new behavior in a bullet, which is a mess and leads to a lot of duplicated code. Instead I solved it with delegates. A bullet has an OnHit delegate, which is called when the bullet hits an object, and of course I can make that delegate anything I like. So now I can create bullets like this

new Bullet(DamageDelegate) 

Which obviously is a much nicer way of doing things.

In functional languages, you tend to see a lot more of this kind of thing.

Answer 2

Delegates are just a way to pass around a function in a variable.

You pass a delegated function to do a callback. Such as when doing asynchronous IO, you pass a delegated function (a function you have written with the delegate parameter) that will be called when the data has been read off the disk.