In this lecture, we'll learn about delegates and event handlers, and how they work together. We'll start by talking about what delegates are. Delegates are a type that specifies a method signature. That may sound really confusing to you. Let's think about it this way. We could have a delegate type that says this method has one integer parameter. We could have another delegate type that says this method has two string parameters. That's all we're talking about is the method signature and a delegate that says, here's what that method looks like. The C-sharp documentation says delegates are like C plus plus function pointers, but they're type-safe. That means nothing to you, perhaps, especially if you've never programmed in C plus plus. Let's think of it this way. A pointer is like a reference, and we know that we can have references to objects in memory. That's what classes are, or the reference types. We can refer to an object in memory, and really what we have is the address of where that object is. Now it turns out that memory holds both data and code. We could also have the address of or a reference for a particular method. That's what the delegates are, they are like a pointer to a particular method. Now, the big idea, the thing that's great is that delegates let us pass a method into another method, and pause for a moment and think about that. We know how to pass arguments into methods. We've passed in numbers and objects, and all stuff. But it delegate lets us pass a method into another method. Here's why that's so powerful. It lets us do something like here. I'm giving you me as a method. If something interesting happens, call me. That's what the event system works like. Delegates are a key piece, because it lets us pass a method into another method so that we get called when something interesting happens. I promised we'd also talk about event handlers. What are event handlers? Well simply stated, an event handler is a method that responds when an event occurs, and put another way. It's just a delegate that has indicated that it is interested in hearing about this event when it happened. Let's look at a pictorial representation of how all this works. Here we have a big honking event in the upper right, and we have an event handler on the left that has said, I am interested in this event. It's called a particular method on the event. Usually that's called add listener, at least in the Unity environment. It basically says add me as a listener for this event, and because the event handler is a delegate, it can pass itself. The event object stores this information and says, well, if I actually fire, then I am going to call this particular method who said they were interested when my event occurs. Same with the event handler on the bottom right, that event handler has also said, I'm interested in this event add me as a listener as well. The event handler on the lower left has not registered to listen for this particular event. They may be an event handler for some other event, but not for this one. That's the first linkage. The event handlers tell the event, hey, I want to know if this event happened. When the event happens, the event calls or invokes each of the methods, the delegates that said they were interested in the event. This is a way for the event to call those methods back and say, hey, I just happened, do what you will with that information. That's really conceptually the way event systems work in general, and certainly the way the events systems that we implement it in our Unity games will work. To recap, delegates let us pass references to methods. That's useful to us because event handlers that match the particular delegates type can call the add listener method for a particular event and say, I'm interested in this event, please let me know when it happens. The event when that event occurs can then invoke each of the methods that said they were interested in the event, because they added themselves as listeners, and that in a nutshell, is the way that event systems work.