Events versus Delegates ??

[Chris]

Hi,

what is the added value of using the 'event' keyword ?

have a look at following (working) code please
(you can just copy/paste and build it) :

using System;
public delegate void WakeUpDelegate();
class AClass
{
public static void WakeUpA()
{
Console.WriteLine("WakeUpA()");
}
}
class Timer
{
public WakeUpDelegate deleg;
public void Alarm()
{
if ( null != deleg )
deleg();
}
}

class Program
{
public static void Main()
{
Timer objTimer = new Timer();
objTimer.deleg += new WakeUpDelegate(AClass.WakeUpA);

objTimer.Alarm();
}
}

My question is :
in class Timer , whether I declare
public WakeUpDelegate deleg;
or
public event WakeUpDelegate deleg;

there is no difference when I run the program, so ...
... what is the added value of using the 'event' keyword ?

When to use events ? When to use just delegates ?

Thnx

Chris

 

[Sam]

The main difference is that in your code the following is
completely valid...

objTimer.deleg();

i.e. anyone can trigger the event, including other
classes or assemblies. (Imagine that anyone could trigger
a disconnected event from say a web browser to tell
everyone listened that they'd been disconnected when in
fact that hadn't happened!)

With the event keyword the above wont compile and the
event can only be triggered from inside class in
question - i.e. the only class that should know if the
event has actually happened.

Sam

 

[Mickey Williams]

A couple of things. First, as a language feature, you can publically expose
an event field, and clients of your class/struct will only be able to use
the += and -= operators against the event.

Second, as an idiom, an event is more contrained than the delegate that
underlies it. Although a delegate can have any number of parameters and can
return a value, an event traditionally follows this pattern:
- always returns void
- always passes two parameters
- the first parameter is a reference to the logical sender
- the second parameter is EventArgs (or a subclass of EventArgs)

These naming constraints are not enforced by the runtime or C# - it's just
The Way We Do Things. If you misbehave, we'll mock you. But seriously, when
you mark a delegate as an event, you're implying that methods attached to
that delegate are invoked one-way, using a predictable notification pattern.

 

[Alvin Bruney]

Why are they synchronous and not asynchronous?

Fire and forget.

 

[Nicholas Paldino [.NET/C# MVP]]

Alvin,

Every delegate exposes a BeginInvoke method. You can call this to
fire-and-forget. Just don't set a callback for the call when it is made.

Hope this helps.

 

[Mickey Williams]

Why are they synchronous and not asynchronous?

Because in the general case the added complexity (due to concurrency safety
issues) and cost of asynchronous invocation overrides the scalability win.
As Nicholas points out, you can always use the asynchronous invocation
pattern against a delegate if you want true FNF semantics. If you take the
explicit step of requesting async invocation, the expectation is that you're
aware of issues like concurrency.

 

[Scott Carter]

The best coverage of this topic has been from Jesse Liberty. Here's a sample
chapter about events and delegates from the 3rd edition of his Programming
C# book: http://www.oreilly.com/catalog/progcsharp3/chapter/ch12.pdf.

Scott

 

[Tom Clement]

I agree completely. But I'd like to note that the .NET framework doesn't
always follow these rules. For example, take a look at the
AppDomain.AssemblyResolve event. The ResolveEventHandler returns an
Assembly. Sort of surprised me when I saw it. I would have expected the
Framework designers to put the return value into the event arguments. Oh
well, I guess even Microsoft can't police everything their developers do.

Tom Clement
Apptero, Inc.

 

[Elwin R.]

When to use events ? When to use just delegates ?

Using delegates is useful when you just need a callback. Take a look
at the System.Threading.Timer class. An instance of this class
doesn't use event notification when a timer event occurs. Instead,
it calls a user defined callback (delegate) that was passed to it at
its creation. Note that this delegate is not made public and cannot
be changed for the lifetime of the object.

I assume this was done because using a delegate as a callback
instead of an event is better for performance reasons? If so, it
probably makes more sense to use a delegate instead of an event when
you want to avoid the overhead of the event mechanism but need a
callback for some kind of notification. In those cases, though, for
the reasons mentioned in this thread, it's not a good idea to make
the delegate public, but better to have it passed to the object when
it is created.

<Disclaimer>
Actually, I'm making some asumptions with what I said above, so I'd
appreciate any comments from those who have more knowledge about
this as it's something I've wondered about myself.
</Disclaimer>