By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,056 Members | 1,320 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,056 IT Pros & Developers. It's quick & easy.

Delegating Events

P: n/a
Say you have a class that raises an event:

public class SomeClass
{
public event EventHandler SomethingHappened;

// ...
}

And another class that uses SomeClass.

public class AnotherClass
{
private SomeClass sc = new SomeClass();

// ...
}

Say that AnotherClass raises an event just like SomeClass. In fact, it
raises this event in response to SomeClass raising its event:

public class AnotherClass
{
private SomeClass sc = new SomeClass();

public event EventHandler SomethingHappened;

public AnotherClass()
{
sc.SomethingHappened += delegate(object sender, EventArgs e)
{
OnSomethingHappened(e);
};
}

protected virtual void OnSomethingHappened(EventArgs e)
{
EventHandler handler = SomethingHappened;

if(handler != null)
{
handler(this, e);
}
}
}

Ok, it seems to me that if AnotherClass doesn't have to do anything
special in response to SomeClass raising its event, AnotherClass could
simply pass along delegates attaching to its SomethingHappened to
SomeClass's event:

public class AnotherClass
{
private SomeClass sc = new SomeClass();

public event EventHandler SomethingHappened
{
add
{
sc.SomethingHappened += value;
}
remove
{
sc.SomethingHappened -= value;
}
}

// ...
}

This seems to be a much cleaner solution. However, there is a potential
problem:

When SomeClass raises SomethingHappened, it passes itself as the sender
parameter. For clients that have attached to AnotherClass's
SomethingHappened event, they may not be expecting an object of
SomeClass's type. Worse, a private object of AnotherClass is being
exposed.

Thoughts?
Sep 26 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Leslie Sanford <ja**********@BiteMeHotmail.comwrote:

<snip>
This seems to be a much cleaner solution. However, there is a potential
problem:

When SomeClass raises SomethingHappened, it passes itself as the sender
parameter. For clients that have attached to AnotherClass's
SomethingHappened event, they may not be expecting an object of
SomeClass's type. Worse, a private object of AnotherClass is being
exposed.

Thoughts?
I think it depends on what's useful at the time. In some situations,
the original object is more useful than the proxying one. In others,
it's the proxy that makes sense. You do need to make sure you document
what will be passed to a handler of the second event though. If the
original class is effectively an implementation detail, there are
encapsulation concerns - but if it's obvious that an instance of that
class is being used, and you don't mind the reference "leaking", then
it needn't be an issue.

The short version of all of the above: "it depends"!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 27 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.