why do we need the "event" keyword while defining events?

Question

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.

e.g.

C#

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 ?

Posted 5-Jan-14 5:16am

Sumit Bhargav

Updated 5-Jan-14 5:26am

Maciej Los

v4

Add a Solution

3 solutions

Solution 3

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.

Posted 5-Jan-14 18:35pm

BillWoodruff

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

OriginalGriff · Accepted Answer · 2014-01-05T05:30:00

Solution 1

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:

C#

customEvent = new CustomEventHandler(customEventHandler);

Instead of

C#

customEvent += new CustomEventHandler(customEventHandler);

If they try, they get a compiler error instead of a difficult-to-track-down run time error.

Posted 5-Jan-14 5:30am

OriginalGriff

Comments

Thomas Daniels 5-Jan-14 11:31am

+5!

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

thanks

OriginalGriff 5-Jan-14 13:34pm

You're welcome!

BillWoodruff 6-Jan-14 1:26am

+5 really appreciate the depth of this response, and the quotation !

CPallini · Accepted Answer · 2014-01-05T05:30:00

Solution 2

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"[^].

Posted 5-Jan-14 5:30am

CPallini