when to use delegates and events

[DKode]

Hello,

I have a question about delegates and events

I have a basic understanding of each, but in the apps I'm building I'm
never needing to use these tools. I'm wondering when and where you
should use these features. I am assuming that they are used in your
presentation layer but perhaps I am sorely wrong.

thank you

Sean

 

[Peter Bromberg [C# MVP]]

DKode,
a delegate is a reference type that provides a generic reference to a
method, with a specific return type and argument list. Delegates are
user-defined types, so when you define a delegate, you are actually defining
a particular type of delegate, not a specific instance.

Your delegate can represent any method at all, provided it has the same
argument list and return type.

Delegates are widely used in .NET -- in multithreaded programming, to
specify the method that is called when a thread is started. They are used
as callbacks in asynchronous programming. Any class or object that has a
"BeginXXX" method is using a delegate.

I frequently use delegates (event delegates) to assist in returning
information from one form to a parent form when it is closed. The parent
form simply becomes an event "subscriber". There are many other uses.
HTH
Peter

 

[Peter Rilling]

Events are not only used in the UI layer, but everywhere where feedback
needs to be provided.

Events provide a way for the object to call back to the main code and
indicates that something has happen where action might need to be taken.

Let's look at things from a human perspective. Suppose that you have a dam
holding back water. You want to make sure that the dam does not break under
pressure. Well, the operator could look at the instrumentation every minute
and compare the value with the expected pressure, but the operator probably
has better things to do. And besides, how often would the operator look at
the instruments -- every minute, or 30 seconds, or sooner.

Now, if the dam was event driven, the dam could have sensors located across
its surface. These sensors would monitor the pressure. If the pressure
gets too high, the sensors will send a signal back to the operator and maybe
flash a light and sound an alert. This will get the operators attention so
the person can open the gates.

The operator looking at the console would be like a program running through
a look or using a thread that wakes periodically. Instead of that, let's
turn the sensors into events. When an event determines the pressure is too
high (PressureOutOfBounds event), the event will create an event delegate
(PressureOutOfBoundsEventHandler delegate) that points to a method that will
sound an alert on the console. The handler receives some parameters
(PressureOutOfBoundsEventArgs) which might contain information like the
current pressure.

 

[Jeff Louie]

One approach is to look at using a delegate when you encounter a
situation
where you would use a callback in C++. So a delegate is a type safe
function
pointer. So a method that does some work can be passed a delegate as a
parameter and when the work is done the method can "callback" the caller
using
the delegate and notify the caller that the work is done. This is much
more
efficient than "polling" where the caller would continue to check to see
if the
work was done at set intervals. Polling can eat up a lot of network
bandwidth.

An event is used when you want to have zero or more listeners register
an
interest in an action. When the action occurs the broadcaster can notify
the
registered listeners of the action. In a sense, the user of your class
can "extend"
the behaviour of your class by registering an interest in an event that
your class
fires.

Regards,
Jeff

 

[Guest]

Delegates are evolved from "function pointers", which when mastered allow a
fundamental increase in the capability a programmer has to design elegant and
powerful object-oriented systems. Function pointers are really what makes OOP
possible.

With proper use of delegates, you can reduce object interdependancy... One
object can service a series of events without ever having direct knowledge of
the other objects who have attached to those events... allowing you to
enhance maintanence, improve extensibility, and reusability of your code.

As a general rule, remember that if you attach a handler to an event
delegate, you should always remove that handler from the event delegate when
your object is disposed.