It's been a while since I have written on this blog, and I'm planning on reviving it this summer, since I have more time to do so again.
I've also recently started working on the iPhone platform, so I haven't been as busy in .NET as before.
In either case, today's blog post applies to both C# and Objective-C, because it's more about a practical understanding of delegates than it is about code. When I was learning coding, I felt like delegates was one of the hardest things to conceptually understand, and a lot of books don't really do a good job (in my opinion) of explaining it. So here's my stab at it.
A Real Life Example of Delegates
Let's say there are three of you. You, your friend, and your brother. You're each in a different room in your house so you can't hear each other, even if you shout.
1)You are playing a computer game
2) Friend is building a puzzle
3) Brother is napping
Now, you three are going to stay in your room but you want to be informed if anything interesting is happening to the one of you. Let's say you (playing the computer game) want to know when your brother wakes up.
You could keep walking to the room, checking to see if he's napping, and then walking back to your room. But that would waste a lot of time / resources, and what if you miss when he's awake before he goes back to sleep? That would be bad.
Instead, you hand him a 2-way radio that works between your room and his room. And you inform him that when he wakes up, he should press a button on the radio and say "I'm awake". You are going to be listening to that radio, waiting for him to say he's awake. This, in essence, is how a delegate works.
You're creating an "object" (the radio) that allows you to listen in on an event you specify. You don't want him to send any other messages to you right now, except when he wakes up. And you want to know immediately when he does, so you can go over to his room and say hi. (the methods that are called when a delegate event fires). You're also currently specifying that only you are listening on his radio.
Let's say you want your friend to come into the room at the same time as you, and do something else entirely, like fluff your brother's pillow. You will then give him an identical radio, that also hooks into your brother's radio, and inform him to wait and listen for the "i'm awake" signal.
Then, when your brother wakes up, he says "I'm awake!" and both you and your friend walk into the room. You say hi, and your friend fluffs the pillow, then you both exit.
Later, if you decide you don't care to say hi anymore, you turn off your radio. Now, you have no idea when your brother is awake or not, because you aren't listening anymore.
So again, you are each classes in this example, and each of you have your own methods. You're playing a computer game (PlayComputerGame()), your friend is building a puzzle (BuildPuzzle()) and your brother is napping (Napping()).
You create a delegate (ImAwake) that you set your brother to do, when he wakes up. You listen in on that delegate (giving yourself a radio and turning it on), and when you receive the message, you fire a new method called SayHi()). Your friend is also wired up to the same delegate (using an identical radio) and fires the method FluffPillow().
Hopefully this makes sense, and helps shed some light on how delegates operate. Let me know! Feel free to drop me a line at Twitter (preferred method of contact) here: samerabousalbi
| posted on Thursday, May 20, 2010 1:01 PM