Events and Delegates

Events are fairly simple to think about. Up until this point, we've told our classes what to do. Any feedback has been as part of the method call. That is, if we want to make a deposit, we tell our Account class to make a deposit. If we want to know our balance, we can ask our Account class. With an event, we can let our class tell us when something happens.

Suppose we have a BankManager class now, and that the Bank Manager wants to know whenever someone tries to deposit more than $10,000 into an account. One way to write this, and a rather inefficient approach, is to have the BankManager ask every Account instance if it has had a large deposit. Another way is to have every Account instance hold a reference to the BankManager. When the Account receives a large deposit, it can let the Bank Manager know. This approach works fine, at least for a while. As soon as the bank hires an Auditor who wants to know of all deposits, then we need to revisit Account and add another reference, this time to the Auditor.

A much simpler approach would be for any interested classes to simply watch the Account. This way, the Auditor would be free to watch and notice every deposit. Meanwhile, the Bank Manager would only pay attention to the large deposits. In a sense, the Bank Manager and Auditors are observers of a subject, the Account.

The heart of the event is another type member – the delegate. Basically, a delegate is a reference to a method of another class. If you have a C or C++ background, you might remember a similar ability through the use of function pointers. One of the big disadvantages of function pointers, though, was that they were not type-safe. In other words, ‘they could attempt to access an invalid memory address’. With a delegate, .NET changes all of that. We now have a first-class member that both allows for callback functions and better ensures things won't blow up at run time.

Events are very powerful and useful mechanisms for designing classes. Rather than constantly monitoring an object for a certain change, that object can simply raise an event. Additionally, it is quite simple to add more subscribers in the future. In this manner, the publishing object is not tied to the subscribers.

However, events, and delegates, should only be used where they make the most sense. They are another tool in your design toolbox, but not the only tool. One large drawback to events is that they do not have to be acted upon. There is no requirement that any class must catch an event thrown by your class. There is a chance that no subscribers have requested to listen for a particular event thrown by your class. As such, you should not throw events that are critical to a class's proper operation. For instance, we couldn't design our Account class to rely on the Auditor class responding to an event. This is because there is no way, using just events, for us to ensure that an Auditor has subscribed to the event. We will cover events and delegates in much more detail in Chapter 6.