Can you overuse delegates and events

Question

I've just started getting to grips with event driven programming and I'm finding delegates and events to be very useful. Since starting to see the potential I've began using them all the time to solve problems such as updating displays between controls and calling stored procedures following updates etc.

I'm starting to use them so frequently that I'm creating and subscribing to events more than I'm actually calling methods manually within the code. Are there any rules to follow in order to know when an event should be used or just a plain old simple function call?

Any advice is greatly appreciated.

Thanks

Answer 1

For me the distinction between using an event and calling a method is for proper separation of concern.

When you call a method, the caller know what method is being called. When you raise an event, the raiser doesn't know who's listening (if anyone at all).

A button control is an excellent example of when an event is appropriate, because a button control doesn't and shouldn't be tied to what it does.

Basically with an event, the actual method that gets called is a variable rather than a constant. This makes it more flexible, but at the same time if it doesn't need to change, it can make the code more complicated to follow.

Answer 2

Yes, you can overuse them.

A few problems that generally come with event-dispatching code:

• Following chains of event handlers in debug mode is very hard.
• In a multi-threaded environment, it becomes even harder.
• Often you end up separating code into phases ("handler installation phase", "event dispatching phase")
• A long-living producer of an event holds references to its consumers. This prevents garbage collection of short-lived consumers if no special care is taken.
• Since the producer holds references to its consumers, it is always stateful. There are scenarios where state is better avoided.

Often you can rewrite complicated, extensively wired event-dispatching code by introducing a new class whose only responsibility is to coordinate a certain process.

Answer 3

I would say the simplest rule is:

• If you know exactly which other method(s) of which other object(s) need(s) to be executed, and there is no need to alter this at runtime, then use a direct call. Helps with readability.
• If you cannot know in advance who would want to receive the information provided by the call, then use an event. Helps with flexibility.

Generally events are used to bubble the reaction of your code to user input up from the lowest layers. Therefore things such as updating a form are usually done through events. This allows you to write proper MVC code, where you could easily write a different view and it would receive the same information, but might react differently to it.

Answer 4

As a rule, you should go with lighter and simplier tool as long as it does the job. The point of events is that we don't know the event handler in advance. It could be anything (any method, as long as it signature matches of course). We could expect it to be passed to us by a call from some other library. That's the luxury here.

I'm sure there is no need to keep all options open like that. Calling methods manually is just much simplier, if you already know what those methods will be. It would make your application easier to understand. Otheriwse it can be a bit like calling friends on a mobile while standing next to them.

Also there's some potential problems with events that you may run into (for example when serializing objects - they will keep reference to their target event listeners, and so they'll try serializing them along, which can give you unexpected results and/or exceptions).