by Ingo Gsedl
11/2009
This article refers to the previous blog 'Event Central'.
After implementing Event Cetnral in a larger application I came up with a few points to keep in mind.
1. Know your events
It is easy to lose track of all the events you send through Event Central.
Solution: keep a list.
Tip: In Event Central I have a section in the format of commenting. It contains a list of all events, with sender and recipient, ordered alphabetically. I am using the following format:
/**
...
classNameEvent
sent by package::className
received by package::className
...
**/
This prevents doublettes.
2.Filter your recipients
When a class has many incidents and the class dispatches events and/or listens for events, dispatching doesn't create a problem - only the one incident sends an event. But a class listening for an event coming from Event Central listens for it in every instance, which may create unwanted processor load.
Example: Event Central dispatches the event 'classNameUpdate' and the class 'Example' listens to it and when the event occurs, 'Example' updates a list. Let's say, there are n instances of 'Example', but the 'update' event is only meant for one instance. If unchecked, the 'update' action is triggered in all instances.
Solution 1: if there is a direct parent-child relation between dispatcher and recipient, do not use Event Central, instead use eventDispatch directly, which allows to identify the target.
Solution 2: when I instantiate the 'Example' class, I give it a unique variable ID:int. In my model class ( in a 'model-view-controller' design pattern the model holds the data ) I have a variable I call currentID:int, which always knows which instance I am currently working on. When I dispatch an event to all instances, all I have to do is make sure that this.ID==currentID before the specific instance reacts to the event.
