Raising events vs direct method calls differences

Question

Raising an event, will call its event handler. eg http://msdn.microsoft.com/en-us/library/aa645739%28VS.71%29.aspx

What is the difference between using the events mechanism and direct calls to other methods (eg if a condition is met in method A(), call B() )?

And what is the difference between consuming and raising events?

Thanks

Answer 1

The difference is this:

Method call = "Do this specific thing"

Event raise = "If anyone is listening and cares, this thing just happened."

It is central to Separation of Concerns and reusability. A button is not a reusable component if clicking it calls a specific method. But if it simply "announces" to the program it was clicked, and interested parties are responsible for subscribing themselves to that, it is infinitely reusable.

The underlying technical implementation of how this is accomplished (via delegate) is irrelevant.

Answer 2

Raising an event, will call its event handler

That started off wrong. There could be no event handler. Or many. You don't know. Which is the major difference from calling a method directly. Look up "observer pattern" in your favorite design patterns book.

Answer 3

What is the difference between using the events mechanism and direct calls to other methods (eg if a condition is met in method A(), call B() )?

Business logic wise there is no difference between the two. What I mean by this is that you can accomplish the same task each way. It's just a different way of going about it. The real difference is the amount of work you have to do to handle the notification of other modules.

With raising an event, you are essentially saying "Hey, something has occurred any piece of code which has signed up to be notified when this happened, let them know. Which modules that get notified is not my concern, because I am assuming that (at runtime) all modules that need to know are setup for notification."

With calling each method directly, you are making the decision that you are going to tell this (or these) modules, and only these, that something has occurred. You are making that assertion that no matter what the states of these modules are in isn't important and they need to know this event happened.

Both are correct for different situations. Event notifications are more dynamic. Different modules can register and de-register for notifications. Direct method calls are more static. A certain set of objects (or modules etc.) are absolutely going to be notified (barring exceptions of course) that something happened, but only these are going to be notified.

Answer 4

Raising an event (or Invoking, to use the term from your link) means you are sending the event to all consumers. For example, a window can raise an event when it is clicked with the mouse.

Consuming an event means that you are receiving and processing the event from whoever sent it. For example, you might want to know when the window is clicked by the mouse.

If you have only one consumer, then you could accomplish something similar by just supplying a callback directly:

// 'Event' type:
delegate void DelMyEvent();
// consumer:
class Consumer
{
    Producer _theProducer;
    void RegisterForNotification()
    {
       _theProducer.OnMyEvent = new DelMyEvent(OnMyEvent);
    }
    void OnMyEvent() { }
}
// producer:
class Producer
{
   public DelMyEvent OnMyEvent;
   void SendNotification()
   {
      if( OnMyEvent != null ) OnMyEvent();
   }
}

The event mechanism cleans this up a bit by preventing the consumer from setting the delegate value directly. Instead it makes the consumer register itself with the += operator. When the first consumer registers, the delegate gets set, and when the second consumer registers, their two callbacks get chained together by Delegate.Combine.