There are a variety of different events that a view might need to handle. The usual strategy is to delegate event handling back to the presenter. However, if the presenter knows exactly what kind of event to handle, this makes for a tight coupling between view and presenter. For instance, what if the view wants to change a button to a menu item? It's a different kind of event handler, so the presenter would also need to change, even if all it cares about is that the item was clicked on. That seems wrong, since the main reason to separate the view and presenter is to give us some flexibility in how to implement the UI.
This class allows the view interface to be structured in terms of a generic event handler. If the presenter is just handling the fact that an event occurred (i.e. that something was clicked), then it won't have to be reimplemented just because the UI element changed. Of course, if the presenter needs to do special handling based on the contents of the event itself, the presenter will still have to change... but in that case we haven't really lost anything.
@author Kenneth J. Pronovici | |
| |