On Mon, 10 Dec 2007 11:31:48 -0800, Sin Jeong-hun <ty*******@gmail.com
wrote:
[...]
Above are simplified version of two classes. The client interacts with
the Manager, and the Manager has many 'Items'. This scheme works but
looks kind of a waste and overhead, because everytime an item fires
ItHapped, OnItHappened is called which simply fires the Manager's the
same event with the same parameters. I just wondered, if this thing
would be possible
Surely it is. But your question is not very clear. For one, the code you
posted wouldn't compile (the Manager class constructor needs a "()" after
the name of the constructor), and even if it did, it wouldn't do anything
because the instance of Item isn't initialized, nor is it referenced
anywhere other than in a local variable. Even if you did subscribe to it,
it doesn't stick around long enough to do anything, at least not as you've
written it here.
Without correct code, it's hard to know for sure what behavior it is you
actually want, since there's no behavior actually being described
unambiguously.
So, I'll make some assumptions about what you want, but if they are wrong
you'll have to elaborate to clear up the misunderstanding.
I'm going to assume that what you want is an event in the Manager class
that, when subscribed to, essentially subscribes to the event in the Item
class. I don't really think that forwarding the event is really all that
big of a problem. But assuming you really want to get rid of the
forwarding, you could implement your event explicitly in the Manager
class, subscribing to the underlying Item event. For example:
class Manager
{
private Item _item = new Item();
public event ItemEventHandler ItHappened
{
add { _item.ItHappened += value; }
remove { _item.ItHappened -= value; }
}
}
That way anyone who tries to subscribe to the Manager event really winds
up subscribing to the Item event.
Note that this actually changes the reference relationships between your
instances. Objects subscribed to the Manager class event now wind up
referenced by the instance of Item, which means that you could release the
Manager instance without releasing the subscribers to the event in
situations where they would have been had they subscribed directly to
something in the Manager class.
If the Item instance is referenced only by the Manager class, that's nota
problem. But if for some reason the Item instance has a lifetime
different from the Manager class, it could create some confusing behavior
for clients of the Manager class (specifically, where the client thought
they'd released the one thing referencing their own instances, when in
fact they hadn't).
I think this is a very important thing to be aware of and is a good reason
to just forward the events through a whole new event unless you have a
very good reason for doing it some other way. There shouldn't be a
significant performance overhead introducing an intermediate event in the
Manager class that forwards events raised by the Item class, and it's a
nice, simple way to do that.
Pete