When should I use events and when delegates?

[beginwithl]

hi

I’m a bit confused about when I should implement events and when
delegates.

BTW: I realize that event is only a modifier that gives controlled
access to its privately declared delegate



1)
a) As far as I understand it, we should choose events over delegates
when encapsulation is of importance and thus we want only for
publisher class to be able to call subscribed methods?


b) But, while it is true that event can only be invoked from within
the class that declares it, couldn’t the same level of encapsulation
be achieved with a delegate object also, assuming we declare it as
being private?



2) In any case, I still don’t know based on what criteria I should
decide when I need the kind of encapsulation ( and thus safety ) the
events offer, and when using the delegate objects would suffice?


3) Are delegates really all that useful by themselves, or do we most
of the times use events? If so, why?



thank you

 

[Peter Morris]

Events are multi-cast, delegates are single. So

SomeClass.SomeEvent can be set from multiple places and when triggered will
execute many delegates.

SomeMethod( this.SomeCallBack ) will pass a single delegate to SomeMethod.

 

[Rudy Velthuis]

Events are multi-cast, delegates are single. So

SomeClass.SomeEvent can be set from multiple places and when
triggered will execute many delegates.

SomeMethod( this.SomeCallBack ) will pass a single delegate to
SomeMethod.

And what is, in this model of yours, a multicast delegate?

 

[Peter Morris]

Hi Rudy

And what is, in this model of yours, a multicast delegate?

I don't understand your question. I don't have a model. Here's an example
where Console.WriteLine is used as a delegate.


List<string> names = new List<string>();
names.Add("Bob");
names.Add("Fred");
names.ForEach(Console.WriteLine);
Console.ReadLine();

 

[Rudy Velthuis]

A "multicast delegate" is one that instead of a single method
reference contains an invocation list, allowing multiple methods to
be invoked with a single invocation statement.

I know.

Due to some quirky history for .NET, all delegate types are actually
multicast delegates.

I also knew that already. That is why I asked what he meant with
"events are multi-cast, delegates are single". <g>

 

[beginwithl]

hi

1) In any case, when deciding between delegates and events, does it in
most cases all comes down to semantics and as such to our own
( subjective ) interpretation of what defines an event?
Thus, one programmer may perceive some action as being an event, and
will thus implement it as an event, while still others won’t interpret
that action as an event?



2)

If you want something in a class that allows you to only ever add or
remove a specific delegate instance...

The event/delegate terminology is a wee confusing at times. So to
clear things up:

Say we want to add an event handler EH to a delegate object D or to
event E --> we could do this with:

D += new D ( some_object.EH );

and

E += some_object.EH;


Now when we register/remove a new event handler, do we say that we
added/removed specific delegate instance( which in turn holds a
reference to some event handler ), or do we say that we added/removed
a specific event handler?



I appreciate all of your help

 

[Rudy Velthuis]

(e-mail address removed) wrote:

"In the .NET Framework class library, events are based on the
EventHandler delegate and the EventArgs base class", right?

IOW, an event is in fact a property implemented by a (multicast)
delegate, with a slightly different syntax. Delegates can be single
cast (as Peter Morris) said, or multicast. In fact, even non-multicast
delegates are multicast, but that is a different story. I assume one
could actually even have events that are single cast, by using get and
set instead of add and remove.

 

[Rudy Velthuis]

An event is not a property.

Syntactically, it may not be, but in reality, it is.

 

[Peter Morris]

I also knew that already. That is why I asked what he meant with

"events are multi-cast, delegates are single". <g>

I'm talking about expected use. If you expect multiple attachments then an
event makes sense, if you want a method to call something back then you
would be passed a delegate (in this case the callback will most likely be a
single cast delegate).

I just think you were cheap point scoring

 

[beginwithl]

thank you all for your kind help

 

[Rudy Velthuis]

In what reality?

It's not a property semantically. It's not a property in
implementation. It doesn't even work like a property.

Ok, if you say so.
--
Rudy Velthuis http://rvelthuis.de

"The secret of a good sermon is to have a good beginning and a
good ending, then having the two as close together as possible."
-- George Burns.

 

[Peter Morris]

If you have no such justification, then I guess that's the end of the

question. But if you do, why not provide it?

To be honest, I was thinking the same thing about your post.

 

[Peter Morris]

I'd say they aren't events, because events have add/remove and properties
have get/set. But most conclusively I think Type.GetEvents() and
Type.GetProperties() indicate that they are completely different things.

 

[Rudy Velthuis]

I'd say they aren't events, because events have add/remove and
properties have get/set. But most conclusively I think
Type.GetEvents() and Type.GetProperties() indicate that they are
completely different things.

The mechanisms are the same though. The principles too. Hejlsberg
copied this over from Delphi and changed syntax a bit. <g>