14

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?

Universal Link
  • 307
  • 1
  • 14
Mohsen Kamrani
  • 7,177
  • 5
  • 42
  • 66

4 Answers4

19

  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.

Lightman
  • 1,078
  • 11
  • 22
  • Your phrase "*Control flow inverted*" is great. It is a little hard to know how to see things that way though... This is why I wonder about teaching programming these days. Fundamental, radically different paradigms must be juggled easily. Sure, ride the bike standing on your head. Simple. –  Oct 14 '15 at 15:31
7

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.

Brian English
  • 466
  • 2
  • 8
  • It's not clear for me from your answer that what is the difference? We can consider every event as a real word entity also we can have a client-server design in OOP. what's new? what's really changed? all of them have already existed. – Mohsen Kamrani Feb 28 '14 at 17:29
  • 2
    The difference lies in the paradigms. I could write an event driven program in COBOL. Let's say I write a server that listens for a request and then sends a response. COBOL is not object-oriented, yet I can write an event driven program in it. The concept of an object oriented language is to be able to create a construct such as a Java class that encapsulates both the data that makes up the object and the actions that the object performs. The object does not necessarily have to respond to events. Event driven programming is a type of program, and object-oriented is more of a type of language. – Brian English Feb 28 '14 at 17:34
  • What I get from your example is that event driven programming is a superset of object oriented programming. Obviously all the objects in an OO program don't respond to events, but in every significant application every object directly or indirectly (as a helper) responds to events. – Mohsen Kamrani Feb 28 '14 at 17:43
  • Think of an object-oriented language as a set of tools that allow you to construct a program. Different languages and different paradigms such as object oriented languages exist to provide varying tool sets to solve problems. Event driven programs seem prominent because those are the most visible programs that you interact with. At work, we work on programs that process batch cycles for banks. These are large programs that process massive data files. While there are some event driven triggers such as report generation, it is just a data processor and does not respond to outside events. – Brian English Feb 28 '14 at 17:48
  • Event driven programs solve event driven problems. It's always best to match the program to the problem it needs to solve, and not vice versa. – Brian English Feb 28 '14 at 17:49
6

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.

2

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.

rje
  • 254
  • 3
  • 10