Events and Delegates

  • Thread starter Thread starter Manco
  • Start date Start date
M

Manco

I've read that events are a C# implementation of the Observer design pattern
which states that:

There is a source object providing an event, subscriber objects can
subscribe to the event and the the source object is responsible for
notifying all events, with 2 parameters part of the event, source object and
event arguments.

Typically in C# this is how it's done:

public delgate void ClickEventHandler(object source, EventArgs e);

class Source
{
// class implementation
public event ClickEventHandler Click;

public void SomeMethod()
{
//... processing
Click(this, new EventArgs()); // raise the event
}
}

public class Subscriber
{
private Source src = new Source();

public void Init()
{
src.Click += new ClickEventHandler(ClickHandler);
}
public void ClickHandler(object source, EventArgs e)
{
// procsessing
}
}

the way I understand it, the C# compiler emits add & remove methods to the
Source class to support the += and -= operators, which simplify the
subscribing of events, or more exactly, combining of MulticastDelegate
objects. The event is simply a MuliicastDelegate object and I could have
done this:

public delgate void ClickEventHandler(object source, EventArgs e);

class Source
{
// class implementation
public ClickEventHandler Click = new ClickEventHandler;

public void SomeMethod()
{
//... processing
Click(this, new EventArgs()); // raise the event
}
}

public class Subscriber
{
private Source src = new Source();

public void Init()
{
ClickEventHandler del = new ClickEventHandler(ClickHandler);
src.Click = del;
}
public void ClickHandler(object source, EventArgs e)
{
// procsessing
}
}

so in the end, the C# event mechanism provides a more efficient syntactical
construct for subscribing to an event then what I did using just
MulticastDelegate members. Please let me know where I'm wrong.

P.S. I know that you can override the .add and .remove handlers for an event
declaration to provide custom processing, which is an addition advantage of
using event keyword.
 
Manco said:
I've read that events are a C# implementation of the Observer design
pattern which states that:

I wouldn't say they are an implementation of the Observer pattern, but they
do provide a pretty clean method of implementing it, IMHO.
Typically in C# this is how it's done:

public delgate void ClickEventHandler(object source, EventArgs e);

class Source
{
// class implementation
public event ClickEventHandler Click;

public void SomeMethod()
{
//... processing
Click(this, new EventArgs()); // raise the event
}
}

public class Subscriber
{
private Source src = new Source();

public void Init()
{
src.Click += new ClickEventHandler(ClickHandler);
}
public void ClickHandler(object source, EventArgs e)
{
// procsessing
}
}

the way I understand it, the C# compiler emits add & remove methods to the
Source class to support the += and -= operators, which simplify the
subscribing of events, or more exactly, combining of MulticastDelegate
objects. The event is simply a MuliicastDelegate object and I could have
done this:

The event is not a MulticastDelegate object anymore than a property is a
string object. The event is the set of methods that provide an interface
access the event implementation and some associated metadata. The event in
and of itself does not actually provide any delegate, the implementation
must do that. The C# compiler just hides that from you in many cases.
so in the end, the C# event mechanism provides a more efficient
syntactical construct for subscribing to an event then what I did using
just MulticastDelegate members. Please let me know where I'm wrong.

for this to be true, your assignment would have to be:

src.Click = (ClickEventHandler)Delegate.Combine(src.Click,del);
 
Back
Top