When should I use events and when delegates?

  • Thread starter Thread starter beginwithl
  • Start date Start date
B

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
 
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.
 
Peter said:
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.
Click to expand...

And what is, in this model of yours, a multicast delegate?
 
Hi Rudy
And what is, in this model of yours, a multicast delegate?
Click to expand...

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();
 
Peter said:
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.
Click to expand...

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

I also knew that already. That is why I asked what he meant with
"events are multi-cast, delegates are single". <g>
 
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...
Click to expand...

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
 
(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.
 
I also knew that already. That is why I asked what he meant with
"events are multi-cast, delegates are single". <g>
Click to expand...

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 :-)
 
Peter said:
In what reality?

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

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.
 
If you have no such justification, then I guess that's the end of the
question. But if you do, why not provide it?
Click to expand...

To be honest, I was thinking the same thing about your post.
 
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.
 
Peter said:
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.
Click to expand...

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