It it possible to redirect events?

  • Thread starter Thread starter Sin Jeong-hun
  • Start date Start date
S

Sin Jeong-hun

class Manager
{
public event ItemEventHandler ItHappened;
public Manager
{
Item i;
i.ItHappend+=new ItemEventHandler(OnItHappened);
}
void OnItHappened(...)
{
this.ItHappened();
}
}
class Item
{
public event ItemEventHandler ItHapped;
}

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
class Client
{
void Init()
{
Manager m;
m.ItHappend += new ItemEventHandler(...);
~~~~~~~~~~~~~~~~~~~~~~ Let's call this thing
X
}
}
class Manager
{
public event ItemEventHandler ItHappened;
public Manager
{
Item i;
i.ItHappend+=somehow get X from Manager's ItHappend handlers;
}
}

If this is possible, then there's no need to call the trivial method
each time. Is it possible to get the handler list of the Manager's
ItHappened event at that point?
Thanks.
 
Sin Jeong-hun,

You could call the GetInvocationList method on the delegate and that
will give you an array of individual delegates that you could the attach
(one-by-one) to the ItHappened event on the Item class.
 
[...]
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
Click to expand...

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
 
[...]
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
Click to expand...

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
Click to expand...

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.
 
Sin Jeong-hun,

You could call the GetInvocationList method on the delegate and that
will give you an array of individual delegates that you could the attach
(one-by-one) to the ItHappened event on the Item class.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)




class Manager
{
public event ItemEventHandler ItHappened;
public Manager
{
Item i;
i.ItHappend+=new ItemEventHandler(OnItHappened);
}
void OnItHappened(...)
{
this.ItHappened();
}
}
class Item
{
public event ItemEventHandler ItHapped;
}
Click to expand...
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
class Client
{
void Init()
{
Manager m;
m.ItHappend += new ItemEventHandler(...);
~~~~~~~~~~~~~~~~~~~~~~ Let's call this thing
X
}
}
class Manager
{
public event ItemEventHandler ItHappened;
public Manager
{
Item i;
i.ItHappend+=somehow get X from Manager's ItHappend handlers;
}
}
Click to expand...
If this is possible, then there's no need to call the trivial method
each time. Is it possible to get the handler list of the Manager's
ItHappened event at that point?
Thanks.
Click to expand...
Click to expand...

Thank you for the simple and easy answer. I'll look into the method.
 
[...]
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.
Click to expand...

I think that given all of that, you might as well stick with the existing
design, in which your Manager has its own event that clients subscribe to,
and which it raises when its own handler subscribed to the Item's event is
executed.

Nicholas and I have both provided alternatives, but I think that in either
of our suggestions, implementing the suggestion needlessly complicates the
implementation. What you've got right now is simple and maintainable and
has no excessive performance overhead.

I'm glad we could answer your question, but I think you didn't really need
us. :)

Pete
 
Back
Top