- the Add Listener method: on / addPropertyChangeListener
- the Fire Event method: fire / notifyPropertyChange
While the naming conventions are different, in spirit they do the same thing. The problem with this approach that if you do instead of:
you won't even notice it unless many hours of pointless debugging have passed.
- the Register Event method: event / addEvent (?)
- the Add Listener method: on / addPropertyChangeListener. Note that this will now throw an exception if an invalid listener will be registered.
- the Fire Event method: fire / notifyPropertyChange. This now can also throw an exception if the event was not registered.
Since we're developers here, some API calls would look like:
Note, that it doesn't mean this should be the final API. Personally I think the best looking API is something along the way that after the registration, you could call the API only via members of the on object. Something like this:
But I am convinced that the actual event types should be tied to the object that can generate them.
In my opinion this approach has these advantages:
- Faster time from the error introduced in the code, to the error report. (we won't generate non existing events, nor listen to non existing ones).
- The possibility of interrogating an object on what events it can raise at runtime.
The only drawback I can think of, is that you can't listen to events before they are registered, but I haven't yet seen any real life application where this actually happens.