Menu
One of my friend recently had an argument in his team about the pros and cons of event driven programming vs sequential programming.
What are your views about it?
746
In sequential programming each command is run many times in sequence. In event-driven programming all commands are run a single time as an event. In sequential programming commands run in the order they are written. In event-driven programming some commands run in response to user interactions or other events.
A sequential program explicitly waits in-line, for the expected events in various places in the execution path. This explicit waiting for events is implemented either by busy-polling or blocking on a time-delay, a semaphore or other such mechanism of a traditional Real-Time Operating System (RTOS).
The opposite of event-driven programming would be software that doesn't need any user input to act. This also covers the case of having various services poll each other for data in timed intervals instead of being triggered by events.
The main difference between event-driven programming and other forms is in how you receive input. With an event-driven approach, much of your code is bundled into event handlers that sit around waiting for the event source to collect the data of an event and notify all handlers.
Two different methods to support two different needs. If you have a problem driven by events, then you should use an event-driven methodology. If you need to perform procedures on defined data, but you're not worried about what's happening elsewhere, then obviously you want to use a more "sequential" style.
Note that typically, these two things are combined. A program's startup, shutdown, and maybe a main processing loop (say, a filter processor in an image app) will be largely sequential, while its UI layer and component interactions are event-driven.
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
