What is the relation of 'Event Driven' and 'Object Oriented' programming?

Question

These days, I hear almost everywhere about 'event driven' programming.

Wikipedia says:

In computer programming, event-driven programming is a programming paradigm in which the flow of the program is determined by events such as user actions (mouse clicks, key presses), sensor outputs, or messages from other programs/threads. Event-driven programming is the dominant paradigm used in graphical user interfaces and other applications (e.g. Javascript web applications) that are centered around performing certain actions in response to user input.

Isn't this exactly our old friend OOP? And if this is not OOP what is the difference?

Answer 1

1. Object Oriented Programming (OOP) and Event-Driven Programming (EDP) are orthogonal, which means that they can be used together.

2. In OOP with EDP all OOP principles (encapsulation, inheritance and polymorphism) stay intact.

3. In OOP with EDP objects acquire some mechanism of publishing event notifications and subscribing to event notifications from other objects.

4. The difference between OOP with / without EDP is control flow between objects.

   • In OOP without EDP control moves from one object to another object on a method call. Object mainly invokes methods of other objects.

   • In OOP with EDP control moves from one object to another object on event notification. Object subscribes on notifications from other objects, then waits for notifications from the objects it is subscribed on, does some work based on notification and publishes it's own notifications.

5. Conclusion: OOP+EDP is "exactly our old friend OOP" with control flow inverted thanks to Event-Driven Design.

Answer 2

Object Oriented Programming is defined by the pairing together of data and actions into a model of a real world object. Event driven programming is a style of programming in which we have a server, whether it be on a communications port or a user interface, waiting for an input command. It will then process that command and display/produce desired results.

Most event driven languages are object oriented. The objects await the events. A program in an object oriented language is not necessarily event driven, and event driven programming does not necessarily require an object oriented language. They are unrelated.

Answer 3

The algorithm of a sequential (non-event-driven) program is like a recipe: begin at the beginning, work through until you get to the end, then stop.

An event-driven program is more like the controls of a car: anything can happen any time in any order.

The Object-Oriented principle seems more applicable to an event-driven model because each of the "controls" is basically unrelated to the others (separation of concerns), and order of events is mostly not important, as is coincidence in time: you can turn on the wipers, turn off the defroster, steer and accelerate all at the same time, and the actions do not affect each other. That is also possible in some cases with a recipe, but it is up to the chef (compiler / optimizer / cpu) to deduce it.

A sequential program can be OO: nobody minds if the blender and the oven are disconnected and do their own thing. I hope this was a useful analogy.

Answer 4

My stab at it. Here are three metaphors:

Event programming seems to be similar to how hardware buses work: a bus is used for peripherals to talk to one another. Similarly, a cell tower is the message bus by which cellphones talk to one another. Also consider the good old Star Network topology model (https://en.wikipedia.org/wiki/Star_network). Heck, look at how a home router connects computers and IoT devices to a home network.

Instead of peripherals or cellphones or devices, we code objects. Instead of sending packets along a transmission protocol, we send events or messages to a message broker (a message queue, for instance, or Kafka). The event is available to be acted upon by whomever is interested in it, or in the case of a workflow, the event is expected to be worked by someone in particular and the sender will expect to find a resulting event with a response appropriate to the outcome.

ASIDE: Lessons Learned

Potentially, we therefore also have solutions about problems that hardware manufacturers and telecom engineers have already encountered and solved regarding event-driven messaging.