Click here to Skip to main content
15,939,853 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I don't understand why do we need the "event" keyword while defining events, when we can do the same thing without using "event" keyword, just by using the delegates.

public delegate void CustomEventHandler(int a, string b);
public event CustomEventHandler customEvent;
customEvent += new CustomEventHandler(customEventHandler);
customEvent(1,"a"); // Raising the event

Here if I remove the "event" keyword from the second line, then also I can raise the event by invoking the delegate. Can anybody please tell me why is this event keyword needed ?
Updated 5-Jan-14 5:26am

You don't - technically - need the event keyword: you can do it with delegates (since events are implemented using delegates that would make sense).

But...using event places some restrictions on the delegate:
"The event keyword indicates to the compiler that the delegate can be invoked only by the defining class, and that other classes can subscribe to and unsubscribe from the delegate using only the appropriate += and -= operators, respectively." (Learning C# 3.0: Master the fundamentals of C# 3.0 by Jesse Liberty, Brian MacDonald, published by O'Reilly Media)

This makes them a little safer, and more reliable, since the event is only invokable from within the class that declares them, and no class can "remove" subscriptions by writing:
customEvent = new CustomEventHandler(customEventHandler);
Instead of
customEvent += new CustomEventHandler(customEventHandler);

If they try, they get a compiler error instead of a difficult-to-track-down run time error.
Share this answer
Thomas Daniels 5-Jan-14 11:31am    
Sumit Bhargav 5-Jan-14 11:37am    
Well i agree with you originalgriff but can you please tell me how does that will help in maling the application loosely coupled?
OriginalGriff 5-Jan-14 11:56am    
No idea.
I wouldn't have thought that using *event* or a "normal" delegate would make any difference - I can't see that either way increases or decreases the interdependence of the classes.
Except...maybe it does in a conceptual way. Because an *event* is a restricted delegate, it does enforce a more "hands off" approach from the classes that use the class defining the event - they can do less with it so they can interact with the class only via more formal, tightly controlled channels, which does - in a way - sort of describe a "looser" coupling between the classes.

But I wouldn't use that as a real guide to the "tightness" of the coupling between two classes myself - there are much more important factors such as the degree of internal exposure the classes present.
Sumit Bhargav 5-Jan-14 12:13pm    
OriginalGriff 5-Jan-14 13:34pm    
You're welcome!
You cannot raise the event, you can just call the event handler (that's a completely different matter).
I suggest you reading a tutorial on C# events and delegates, see, for instance this Code Project article: "Events and Delegates Simplified"[^].
Share this answer
To add to the excellent replies here, I'd like to emphasize that Events are not Fields, and a Delegate is a Field. The += and -= operators are not forms of "assignment," but are methods that bind a name (the invocation name) ... or remove a bound-name and its associated method ... to a supplied method which is then stored in a specific "slot" in the Event's queue of invocation methods (multi-cast delegate list).

I find Jon Skeet's explanation of this very illuminating: [^]. If you can get the 3rd. edition of "C# in Depth" by Jon Skeet (Manning Press), the chapter on Delegates and Events, imho, is "worth its weight in gold:"

... p. 36

"Developers often confuse events and delegate instances, or events and fields declared with delegate types. The difference is important: events aren’t fields. The reason for the confusion is that C# provides a shorthand in the form of field-like events.

... p. 37

Field-like events make the implementation of all of this much simpler to look at—a single declaration and you’re done. The compiler turns the declaration into both an event with default add/remove implementations and a private field of the same type. Code inside the class sees the field; code outside the class only sees the event. This makes it look as if you can invoke an event, but what you actually do to call the event handlers is invoke the delegate instance stored in the field."

J. Skeet, "C# in Depth, 3rd. Edition, Section 2.13, p. 36~37.
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900