Event Oriented Programming

Event Oriented Programming – Features and Options

Event oriented programming is often said to produce spaghetti code which is difficult to debug. I believe these are skill-related issues, and the event-oriented programming model needs to be mastered like every other programming model. For example, signal processing diagrams in backend testing can help to document programs following the event-oriented model. Special debugging tools assign every callback a complete stack trace so that one can trace back the source of a given problem if he must.

Non-blocking I/O

Non-blocking or asynchronous I/O allows the computation to continue while the input/ output operation is running. So it is, for example, possible to have multiple database queries running at a time. Input and output operations on the network or file can be extremely slow compared to the processing of data in memory. Most of I/O operations involve disc access in some form and spinning of discs is orders of magnitude slower than read/ write operations on an electronic circuit.

There are different forms of non-blocking I/O like polling, signals, and callbacks.

1. Greenlet

Greenlets or event lets in companies that offer testing services are an abstraction on top of an event loop. When using greenlets, one is programming in a blocking way, and the framework is using the event loop and a scheduler under the hood. The programming model is more like threads but avoiding resource consumption.

2. Callbacks

A callback is a function, that is passed as an argument to I/O operation. Once the I/O operation is completed the part of the program which deals with the results of this operation is invoked. It is possible to use anonymous callbacks, but this is considered bad practice since it makes programs difficult to read. Therefore named callbacks are to be preferred over anonymous callbacks.

3. Event-loop

The event loop, also called message dispatcher is a programming construct that waits for and dispatches events or messages in a program. It works by polling some internal or external “event provider”, which generally blocks until an event has arrived, and then calls the relevant event handler (“dispatches the event”).

Ted Faison’s book “Event-Based Programming: Taking Events to the Limit” proved very helpful to me in understanding the ins and outs of event-oriented programming. The book follows a structured approach and is very well written.

According to Faison, the event programming model is by far the superior programming model, especially for large software systems. Dependencies between software parts make large software systems complex and difficult to maintain. Dependencies have the biggest impact on software quality since the most complex parts also have the most dependencies. The event-oriented programming model helps you gain better modularization, so development, testing, and maintenance of parts of the system are more comfortable. Farson makes a point that by following the event-oriented programming, model complexity grows linear with the size of the system while you will experience exponential grows when following other models. If this proves to be true, this will be the biggest discovery in software engineering for the last decade.


Leave a comment

Your email address will not be published. Required fields are marked *