Event models and Event driven programming

Traditional web applications have a sequential flow, A form which is filled and submitted to controller, and some magic before showing a html page. Rich GUI on the other hand supported event driven flow. A button clicked on form causes the controller/presenter to sense data from widgets (data-binding), then some magic and finally a view is shown to the user. If the logic of rendering is built into view it is MVC, if any intermediate intelligent helper is present it is MVP. Until the advent of AJAX, web applications could not benefit from event driven style of programming. Reason: server-side code could not listen on client side entities.

What is event driven code any way? Lets understand what is not event driven. A program is typically a list of chores. This is procedural. The program is to be thought of a continuous loop only pausing for inputs. Once an input is given the program runs and marks an internal state (session state). Then there is another input, the program again runs and updates the internal state. Some of these states are shown to the user using conditional logic. This is not important, the important point is to note how the program is processing inputs in a sequential pattern. In case you are wondering, I made the most blatant assumptions about multi-tasking abilities of the underlying process. In reality, the inputs are accepted in a different thread/process and passed on using multi-threading and multi-processing. Thus simulating the concurrent execution and support for multi-user paradigm.

In event driven, the program is thought to be comprised of multiple standalone modules each of which can be triggered independently. A user inputs triggers only portions of program, depending on their nature. The state is set in these portions. The user inputs assume no sequential flow. There can be multiple triggers and no assumptions are made about order of triggering. The keyboard is a good analogy, to play a tune the user selects the keys and changes the state. Most real world tasks are event-driven. Unfortunately, in CS the mind set is rather procedural.

Do you see any problems with event-driven approach? Event driven code relies on underlying sequential code. This causes unwanted side-effects. For eg: if the code itself is capable of creating events or user triggers multiple events the order in which events are raised cause a huge furore, nearly impossible to debug as they are difficult to be repeated. I once had a code which ran perfectly in debug mode when I was stepping through and just refused to yield in run mode. Mea-culpa. The solution prevent user-inputs when undesired (by locking the application). Try to queue up events if required.

Another problem, the observer-observable pattern causes a mesh. It is nearly impossible to keep track of who is listening to whom. The whereabouts of event are cryptic when visualising the big picture. Another problem, the observers need a handle/reference to observable. So there would be unwanted reference propagation. The solution, I call it message exchange. I tried to address this issue by making a bulletin analogy. Observables are only observed by the bulletin, in turn the bulletin takes the responsibility of broadcasting the events globally. Observers only listen to bulletin. The bulletin is sort of radio station or telephone exchange.

Think of this mathematical problem, if there are N houses with telephones and each of them need a line to call other, how many lines are required? N(N-1)/2 is the answer. It is O(N^2). For 10 houses it would be 45, for 12 houses it is 66. A difference of 2 and see the extra lines required. With a message exchange the increase is linear. For 10 houses we need 10 lines and for 12 houses it is 12 lines. The penalty is paid in real-world in terms of dropped calls or busy tones. Under the sufficient assumption that computers are fast, we can get away with this. However, it is always a good practice to freeze the application and thus preventing unwanted inputs. One may wonder about concurrency, in a properly designed application the freeze would be applicable for a single user (especially session state). Another advantage of message exchange is the ability to debug/analyse the application. The testability of application also improves greatly.