See Also:
As a web dev, I don’t typically have to get into building my own events for objects, since most are inherent in the page. However, now I’m into a pretty complex (web) project where I think I may have to use them. I just read a chapter out of Pro VB 2008 and the .NET 3.5 Platform regarding events, delegates and lambdas (ch. 11) and while I have a better idea of what’s going on, I am still having trouble wrapping my mind around when exactly to use them and how to use them. I understand their implementation, but the example in the book is a bit contrived.
I was hoping someone with a bit more understanding on the subject of events could provide me with a really solid example.
For my real-world application, I’m trying to use an event that would let me know when an item (some class, named OrderItem) has been updated and perform actions based on whether or not it’s been updated. I considered using a flag/boolean property, but I know this doesn’t smell right, and it’s high-time I learn about how to use events correctly.
Thanks a lot!
EDIT Ok, so I guess to clarify a bit, what is the point of calling an event when all it is doing is calling a method? Why not simply call the method? This isn’t a duplicate either, as I’m talking conceptually and she wants to know about handlers specifically. Also, I want to know what the difference would be between using an event or a "flag" property. And what do people mean by "subscribe" to an event?
Events are a specific case of the Inversion of Control (IoC) pattern. The traditional control flow, the caller invokes a method on the callee (like you are suggesting). With IoC (and thus events), we change around the application control and instead of tell the callee what to do, we tell the callee to notify us when something we are interested in happens.
Consider the case of a Timer. I want to be notified every 5 seconds (say). I don’t want to constantly poll the timer (“is it time yet? is it time yet? is it time yet?”). Instead, I want to invert the flow control of my application. I want to tell the timer: “When it’s time, please tell me by calling this method.” That way, control is “inverted”, the callee is invoking a method on the caller!
Consider the following code …
Rather than call a method on the Timer to ask when it will go off again (as you suggest), I tell it, “when you go off, call the TimerGoesOff” method. Now, instead of just waiting for the Timer to go off, I could do some work. Consider this code …
Now, I get output something like …
I have used the Timer.Elapsed Event to change the control flow of my application. I can go off and do work while “waiting” for the timer event to pulse. This is made possible by IoC and Events.
This is particularly visible (hehe) in User Interfaces. I don’t want to keep asking “has the user done anything yet? has the user done anything yet?” (that’s the way it used to be done way back when). Instead, I tell Controls for example, “when the user clicks you, let me know”. That way, I can go off and do other great stuff and still be responsive to the user.