Re: It it possible to redirect events?
- From: Sin Jeong-hun <typingcat@xxxxxxxxx>
- Date: Tue, 11 Dec 2007 12:56:22 -0800 (PST)
On Dec 11, 5:00 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
On Mon, 10 Dec 2007 11:31:48 -0800, Sin Jeong-hun <typing...@xxxxxxxxx>
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 not a
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
I really appreciate your time on my question. It is really a detailed
answer!
First of all, that codes in my original post were not realy codes.
Real codes
were long so I only depicted parts necessary to explain the question,
all names
of classes, methods or events are boguses. Sure it wouldn't compile.
What I was trying to say was like this.
1.Client doesn't directly interacts with Item because there are two
many Items.
2.Client intereacts with Manager
3.Item fires ItHappened events.
4.Client should respond to ItHappened events.
5.Since Client doesn't directly instantiate Items, Client subscribes
to the Managers ItHappened events.
6.Manager's ItHappened event is nothing but simply redirecting
ItHappened events from its many items.
7.According to my oroginal scheme, everytime an ItHappened event fired
from an Item, A method in the Manager is called, which simply fires
its ItHappened events, thus redirecting it to the Client.
8.In 7, calling the method each time seemed like an overhead.
Now, I'm going to read carefully what you've written. Thanks again.
.
- Follow-Ups:
- Re: It it possible to redirect events?
- From: Peter Duniho
- Re: It it possible to redirect events?
- References:
- It it possible to redirect events?
- From: Sin Jeong-hun
- Re: It it possible to redirect events?
- From: Peter Duniho
- It it possible to redirect events?
- Prev by Date: Re: Parser Theory - Using grammars to build parsers
- Next by Date: Re: It it possible to redirect events?
- Previous by thread: Re: It it possible to redirect events?
- Next by thread: Re: It it possible to redirect events?
- Index(es):
Relevant Pages
|
