Selective signaling

[wysota]

Basically we are talking about same thing, except the fact that you are using a list of Item's to hold the N observers, and at each event you are traversing the entire list of observers, to notify the observers if they are interested (you can have 10000 of observers, while only the last one is interested in the event you want to notify him about) , while I'm using N lists of observers, one for each type of event, and I use the list of slots registered on helper object's signal.

See my comment in the code - I know it's inefficient, I only wanted to show the functionality without cluttering the code too much.

If your code were storing for each event type a list of notifiers, and then the solution was mostly the same, except of course the fact that in your code you have the loop to deliver the event, while I'm using Qt's signal-slot calling, which basically in the end reduces down to same thing, going over a list of interested parties, and call them.

What happens (with your code) when one object subscribes to multiple types of messages or messages of the same type coming from different objects? How does handleEvent() look like then?

[csaken]

Usually each processor handles one type of event or a small group of events.
If I decide to subscribe the same processor to more than one event, nothing changes in the way they are registered, or how it's called.

From the event router's point of view does not matter, since he has for each event type a QObject,and each of these helper objects has a list if slots queued up.

Still, in this case, in the Processor's code, I have to check for what signal was called, and proceed accordingly. However, the processors get called only for the event types they are interested in.

Processor1::handleEvent(Event* e)
{
   if(typeofEvent is Event1) { ... }
   if(typeofEvent is Event2) { ... }
}
 
EventRouter r;
Processor p;
r.register(typeofEvent1, &p);
r.register(typeofEvent2, &p);
 
r.fireEvent(new Event1()) // triggers Processor 1, since is in the typeofEvent1's list of queued slots for event() signal
r.fireEvent(new Event2()) // also triggers Processor 1, since it is also in the list of typeofEvent1;s list of queued slots for event() signal.

Processor1::handleEvent(Event* e)
{
   if(typeofEvent is Event1) { ... }
   if(typeofEvent is Event2) { ... }
}

EventRouter r;
Processor p;
r.register(typeofEvent1, &p);
r.register(typeofEvent2, &p);

r.fireEvent(new Event1()) // triggers Processor 1, since is in the typeofEvent1's list of queued slots for event() signal
r.fireEvent(new Event2()) // also triggers Processor 1, since it is also in the list of typeofEvent1;s list of queued slots for event() signal.

To copy to clipboard, switch view to plain text mode 

Also, the event sending mechanism I want to be lousy coupled, I'm not interested in who sent the event, I'm only interested in getting it from somewhere, and handling it then possibly send some more events, somewhere. Controllers on different layers will take care of sending up/down the events, although they are also not interested from where comes, only the direction, up or down (I think, I'm still ironing out things on this side)