Computer Science
Event Driven Programming
Event-driven programming is a programming paradigm in which the flow of the program is determined by events such as user actions, sensor outputs, or messages from other programs or threads. The program responds to these events by executing code that is associated with them, allowing for more flexible and responsive applications.
Written by Perlego with AI-assistance
Related key terms
6 Key excerpts on "Event Driven Programming"
eBook - ePubExpert Python Programming
Master Python by learning the best coding practices and advanced programming concepts, 4th Edition
- Michał Jaworski, Tarek Ziadé(Authors)
- 2021(Publication Date)
- Packt Publishing(Publisher)
messages ) and their flow between different software components. In fact, it can be found in many types of software. Historically, event-based programming is the most common paradigm for software that deals with direct human interaction. It means that it is a natural paradigm for GUIs. Anywhere the program needs to wait for some human input, that input can be modeled as events or messages. In such a framing, an event-driven program is often just a collection of event/message handlers that respond to human interaction.Events of course don't have to be a direct result of user interaction. The architecture of any web application is also event-driven. Web browsers send requests to web servers on behalf of the user, and these requests are often processed as separate interaction events. Some of the requests will indeed be the result of direct user input (for example, submitting a form or clicking on a link), but don't always have to be. Many modern applications can asynchronously synchronize information with a web server without any interaction from the user, and that communication happens silently without the user noticing.In summary, event-driven programming is a general way of coupling software components of various sizes and happens on various levels of software architecture. Depending on the scale and type of software architecture we're dealing with, it can take various forms:- It can be a concurrency model directly supported by a semantic feature of a given programming language (for example, async /await in Python)
- It can be a way of structuring application code with event dispatchers/handlers, signals, and so on
- It can be a general inter-process or inter-service communication architecture that allows for the coupling of independent software components in a larger system
Event-driven != asynchronous
Although event-driven programming is a paradigm that is extremely common for asynchronous systems, it doesn't mean that every event-driven application must be asynchronous. It also doesn't mean that event-driven programming is suited only for concurrent and asynchronous applications. Actually, the event-driven approach is extremely useful, even for decoupling problems that are strictly synchronous and definitely not concurrent.
eBook - ePubExpert Python Programming
Become a master in Python by learning coding best practices and advanced programming concepts in Python 3.7, 3rd Edition
- Michał Jaworski, Tarek Ziadé(Authors)
- 2019(Publication Date)
- Packt Publishing(Publisher)
Events also don't have to be a direct result of user interaction. The architecture of any web application is also event-driven. Web browsers send requests to web servers on behalf of the user, and these requests are often processed as separate interaction events. Such requests are, of course, often the result of direct user input (for example, submitting a form or clicking on a link), but don't always have to be. Many modern applications can asynchronously synchronize information with a web server without any interaction from the user, and that communication happens silently without the user's notice.In summary, event-driven programming is a general way of coupling software components of various sizes, and happens on various levels of software architecture. Depending on the scale and type of software architecture we're dealing with, it can take various forms:- It can be a concurrency model directly supported by a semantic feature of given programming language (for example, async/await in Python)
- It can be a way of structuring application code with event dispatchers/handlers, signals, and so on
- It can be a general inter-process or inter-service communication architecture that allows for the coupling of independent software components in a larger system
Passage contains an image
Event-driven != asynchronous
Although event-driven programming is a paradigm that is extremely common for asynchronous systems, it doesn't mean that every event-driven application must be asynchronous. It also doesn't mean that event-driven programming is suited only for concurrent and asynchronous applications. Actually, the event-driven approach is extremely useful, even for decoupling problems that are strictly synchronous and definitely not concurrent.Consider, for instance, database triggers that are available in almost every relational database system. A database trigger is a stored procedure that is executed in response to a certain event that happens in the database. This is a common building block of database systems that, among others, allows the database to maintain data consistency in scenarios that cannot be easily modeled with the mechanism of database constraints. For instance, the PostgreSQL database distinguishes three types of row-level events that can occur in either a table or a view:
eBook - ePub- Sandro Pasquali, Kevin Faaborg, Glenn Geenen(Authors)
- 2017(Publication Date)
- Packt Publishing(Publisher)
The key design choice made by Node's designers was the implementation of an event loop as a concurrency manager. For example, notifying your Node-based HTTP server of network connections to your local hardware is handled by the OS passing along, via libuv, network interface events.The following description of event-driven programming (taken from: http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Event-driven_programming.html ) clearly not only describes the event-driven paradigm, but also introduces us to how events are handled in Node, and how JavaScript is an ideal language for such a paradigm.In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—that is, sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads. Event-driven programming can also be defined as an application architecture technique in which the application has a main loop that is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling […]. Event-driven programs can be written in any language, although the task is easier in languages that provide high-level abstractions, such as closures. Visit https://www.youtube.com/watch?v=QQnz4QHNZKc for more information.Node makes a single thread more efficient by delegating many blocking operations to OS subsystems to process, bothering the main V8 thread only when there is data available for use. The main thread (your executing Node program) expresses interest in some data (such as via fs.readFile) by passing a callback, and is notified when that data is available. Until that data arrives, no further burden is placed on V8's main JavaScript thread. How? Node delegates I/O work to libuv, as quoted at: http://nikhilm.github.io/uvbook/basics.html#event-loops .In event-driven programming, an application expresses interest in certain events, and responds to them when they occur. The responsibility of gathering events from the operating system or monitoring other sources of events is handled by libuv, and the user can register callbacks to be invoked when an event occurs.
eBook - ePubEvent Processing for Business
Organizing the Real-Time Enterprise
- David C. Luckham(Author)
- 2011(Publication Date)
- Wiley(Publisher)
thought of as happening —like using your imagination to visualize the events that will happen if you don’t stop at a red light. Suppose, for example, there’s a car crossing on green, and you imagine a crash! But since you stopped at the red light, those events didn’t happen—you imagined them as virtual events. And you used them in decision making.Event Driven SimulationEvent driven simulation refers to the use of events to drive the steps in computing with models to predict the behavior of systems—anything from a design for a controller for traffic lights, or a model for a manufacturing line, to a plan for battlefield operations. This is one of the earliest uses of events and event driven computing. Rooted in World War II, this area of computer programming took off in the 1950s. People started to use computers—a recent invention at the time—to predict how designs of devices such as controllers would behave before they were actually manufactured. The idea was to save costs involved in letting mistakes in designs go forward to the manufacture of the design and also to shorten the time taken in the design-to-manufacture cycle.Computer simulation started out very simply as a haphazard activity in which people wrote programs, usually in machine code, to predict the behavior of a design or model. The activity quickly expanded to other things, such as predicting how the operations of a company could be improved to grow sales, and later on to much more ambitious undertakings like forecasting the weather.3During the 1950s, the techniques for building computer simulations quickly became understood and formalized. The core idea is to use a computer program that models—or mimics—an actual system. The system could be anything from a factory production line to a company’s sales plans to voter behavior in an election. Simulation refers to executing the model on input data. It turned out that many simulations used events as a way to organize their computations. The event driven
eBook - ePubSoftware Architecture with Spring 5.0
Design and architect highly scalable, robust, and high-performance Java applications
- René Enríquez, Alberto Salazar(Authors)
- 2018(Publication Date)
- Packt Publishing(Publisher)
Event-Driven Architectures
Event-driven architectures (EDA ) are based on commands and events that are created each time an application changes stat e. According to Martin Fowler, there are four patterns that are used to build software systems using this approach.In this chapter, we are going to learn about these four patterns and look at how messaging can be tied together to take full advantage of a programming model based on messages. Even when it's not a requirement, messaging can be used to add more capabilities into applications that are built using an event-driven architectural style.In this chapter, we will look at the following topics:- Underlying concepts and key aspects associated with event-driven architectures:
- Commands
- Events
- Common patterns used within event-driven architectures:
- Event notification
- Event-carried state transfer
- Event sourcing
- CQRS
Passage contains an image
Underlying concepts and key aspects
Before looking into the details of event-driven architectures, we are going to start by learning about some key aspects surrounding them. The applications created using this approach are developed with two different but related concepts in mind:- Commands
- Events
Passage contains an image
Command
Commands are called actions. This makes a lot of sense if we take their intended use into consideration. The following list shows some examples of such commands:A command is an operation performed within an application that emits one or more events as the result of a successful or failed execution. We can think about these as operations that are intended to modify the state of a system.- Transfer money
- Update user information
- Create an account
Passage contains an image
Event
An event is the result of a command execution within an application. These are used as a notification mechanism for subscribers who are interested in receiving them. Events are immutable and should not be modified, as they are designed to keep a log that keeps information on how the application state has mutated over time.
eBook - ePub- Peter Niblett, Opher Etzion(Authors)
- 2010(Publication Date)
- Manning(Publisher)
Chapter 2. Principles of event processing
An apprentice carpenter may want only a hammer and saw, but a master craftsman employs many precision tools. Computer programming likewise requires sophisticated tools to cope with the complexity of real applications, and only practice with these tools will build skill in their use.Robert L. KruseIn the previous chapter we briefly introduced event processing. In this chapter we explore the technical concepts behind event processing in more detail. The chapter is divided into three main sections:- In section 2.1 we look at the event-based programming part of event processing. This covers the event aspect of event processing. The remainder of the chapter then discusses the processing part of event processing.
- In section 2.2 we introduce the main concepts of event processing, and define the terminology we use to describe them.
- In section 2.3 we introduce the modeling language that we use in this book to describe the concepts from section 2.2 .
This chapter focuses on the general principles underlying these topics. In part 2 of this book we show them being used in the Fast Flower Delivery example that we introduced in the previous chapter.2.1. Events and event-based programming
In the first part of this chapter we look more closely at events in computerized event processing, their interactions with application components, and the ways they are distributed between these components. As a lead into this, however we start by looking at how applications components typically interact when they aren’t using events.2.1.1. The background: request-response interactions
Everyone who has used a web browser (figure 2.1
Index pages curate the most relevant extracts from our library of academic textbooks. They’ve been created using an in-house natural language model (NLM), each adding context and meaning to key research topics.
