This article's factual accuracy is disputed. Please see the relevant discussion on the talk page. (October 2009)

This article may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (October 2009)

Programming paradigms

Agent-oriented Component-based Flow-based Pipeline Concatenative Concurrent computing Declarative (contrast: Imperative) Functional Dataflow Cell-oriented (spreadsheets) Reactive Graph-oriented Goal-oriented Constraint Logic Constraint logic Abductive logic Inductive logic Event-driven Service-oriented Feature-oriented Function-level (contrast: Value-level) Imperative (contrast: Declarative) Non-structured Array (contrast: Scalar) Iterative Structured Procedural Modular Recursive Object-oriented Class-based Prototype-based Automata-based By separation of concerns: Aspect-oriented Subject-oriented Role-oriented Metaprogramming Attribute-oriented Automatic Generic Template Policy-based Language-oriented Domain-specific Grammar-oriented Dialecting Intentional Reflective Nondeterministic Parallel computing Process-oriented Programming in the large and programming in the small Value-level (contrast: Function-level) This box: view • talk • edit

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—i.e., 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 which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.

Event-driven programs can be written in any language, although the task is easier in languages that provide high-level abstractions, such as closures. Some integrated development environments provide code generation assistants that automate the most repetitive tasks required for event handling.

Contents 1 Contrast with batch programming 1.1 Batch version 1.2 Event-driven version 2 Example: reading from a socket 3 Event handlers 3.1 A trivial event handler 3.2 Exception handlers 4 Creating event handlers 5 Binding event handlers 6 Main loop 7 See also 8 References 9 External links

[edit] Contrast with batch programming

In contrast with batch programming, the flow is determined by the programmer. Although batch programming is the style taught in beginning programming classes, the more complex event-driven programming is the standard architecture of modern interactive programs.

Here are two pseudocode versions of a trivial program to add two numbers:

[edit] Batch version

 read a number (from the keyboard) and store it in variable A[0] read a number (from the keyboard) and store it in variable A[1] print A[0]+A[1] 

[edit] Event-driven version

 set counter K to 0 repeat {    if a number has been entered (from the keyboard)    {      store in A[K] and increment K      if K equals 2 print A[0]+A[1] and reset K to 0    } } 

At first sight, the event-driven program seems more cumbersome and for such a trivial task it really is. However, the second program can be generalized far more easily than the first. Instead of checking just for a number entry we may add code to check whether any of several events has occurred. Then for each event we can execute a particular piece of code that is commonly referred to as an event handler.

A slight variation in the above further illustrates the point:

 set counter K to 0 repeat {    whenever a number has been entered (from the keyboard) // keyboard-number event    {      store in A[K] and increment K // keyboard-number handler    }    if K equals 2 // ready-to-sum event    {      print A[0]+A[1] and reset K to 0 // ready-to-sum handler    } } 

[edit] Example: reading from a socket

This section overlaps with other sections too much. It should be combined with the rest of the article. Please improve this article if you can.

This example uses pseudocode to illustrate how data is read from a socket using an event-driven approach:

 function read_next_data(fd)    data = read_async( fd )    if len(data) == 0        => Nothing to read, register to be called back when something is ready        event_polling_register( fd, read_next_data )        => Go back to doing something else    else        => Data was available and len(data) was received        add_data_to_buffer( buffer, data )    end_if end_function 

[edit] Event handlers

Because the code for checking for events and the main loop does not depend on the application, many programming frameworks take care of their implementation and expect the user to provide only the code for the event handlers. In this simple example there may be a call to event handler called OnKeyEnter() that includes an argument with a string of characters, corresponding to what the user typed before hitting the ENTER key. If we want to add two numbers we need to use storage outside the event handler, so the implementation might look like this

[edit] A trivial event handler

 globally declare the counter K and the integer T. OnKeyEnter(character C) {    convert C to a number N    if K is zero store N in T and increment K    otherwise add N to T, print the result and reset K to zero } 

While keeping track of history is straightforward in a batch program, it requires special attention and planning in an event-driven program.

[edit] Exception handlers

In some programming languages (eg PL/1) ,even though a program itself may not be predominantly event driven, certain abnormal events such as a hardware error, overflow (software) or "program checks" may occur that possibly prevents further processing. Exception handlers, may be provided by "ON statements" in (unseen) callers to provide housekeeping routines to clean up afterwards before termination.

[edit] Creating event handlers

The first step in developing an event-driven program is to write a series of subroutines, or methods, called event-handler routines. These routines handle the events that the main program will respond to. For example, in a GUI program, we might be interested in a single (as opposed to a double) left-button mouse-click on a command button. So a routine would be written to respond to such an event. The routine might open another window, save data to a database or exit the application. Many modern day programming environments provide the programmer with event templates so that the programmer need only supply the event code.

[edit] Binding event handlers

The second step is to bind event handlers to events, so that the correct function is called when the event takes place.

Graphical editors combine the first two steps: double-click on a button, and the editor creates an (empty) event handler associated with the user clicking the button and opens a text window so you can edit the event handler.

[edit] Main loop

The third step in developing an event-driven program is to write the main loop. This is a function that checks for the occurence of events, and then calls the matching event handler to process it. Most event-driven programming environments already provide this main loop, so it need not be specifically provided by the application programmer. RPG, an early programming language from IBM, whose 1960s design concept was similar to event driven programming discussed above, provided a built-in main I/O loop (known as the "program cycle") where the calculations responded in accordance to 'indicators' (flags) that were set earlier in the cycle.

[edit] See also

• DOM events
• Event-driven architecture
• Event Stream Processing (a similar concept)
• Hardware Description Language
• Inversion of control
• Message-oriented middleware
• Programming paradigm
• Publish/subscribe
• Signal programming (a similar concept)
• SEDA
• Virtual synchrony, a distributed execution model for event-driven programming

[edit] References

[edit] External links

• Description from Portland Pattern Repository
• Tutorial "Event-Driven Programming: Introduction, Tutorial, History" by Stephen Ferg
• Tutorial "Event Driven Programming" by Alan Gauld
• Article "Event Collaboration" by Martin Fowler
• Article "Transitioning from Structured to Event-Driven Programming" by Ben Watson
• Article "Rethinking Swing Threading" by Jonathan Simon
• Article "The event driven programming style" by Chris McDonald
• Article "Event Driven Programming using Template Specialization" by Christopher Diggins
• Article "Concepts and Architecture of Vista - a Multiparadigm Programming Environment" by Stefan Schiffer and Joachim Hans Fröhlich
• Chapter "Event-Driven Programming and Agents"
• LabWindows/CVI Resources
• Comment by Tim Boudreau
• Complex Event Processing and Service Oriented Architecture [1]
• Event-driven programming and SOA: How EDA extends SOA and why it is important Jack van Hoof
• For an open source example which is in production on MSN.com and Microsoft.com, see Distributed Publish/Subscribe Event System
• For C-Code generation from UML State-Charts for Embedded Systems see Sinelabore.com
• StateWizard - A ClassWizard-like event-driven state machine framework and tool running in popular IDEs under open-source license.