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.


  • 6
    Don't forget the old adage - "To a man with a hammer, everything looks like a nail". The question you need to keep in mind is "What is using an event giving me that a plain function call does not, IN THIS CASE, and do I need it?" Jul 29, 2011 at 15:28
  • 1
    You might get a more precise answer if you could post the some code for a specific case where you are undecided. Jul 29, 2011 at 16:02

4 Answers 4


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.


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.


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.


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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.