Events

introduction teaching contracts patterns events examples foundations conclusions references

The concept of event is used in the context of modeling the behavior of systems and as a generic term for the effect of user actions in a window environment. Events, obviously, play a dominant role in (object-oriented) GUI frameworks. However, events may also be employed as a high level modeling and implementation device to characterize the interaction of a user with the system and to encapsulate complex interaction patterns between objects in a uniform manner.

Problem

Anyone developing a window application for the first time must get used to the fact that control is no longer program-defined (determinate) but that, instead, the computation depends on the occurrence of events. Although the use of callbacks actually simplifies the programming task, students experience difficulty in understanding the indirection involved and the requirements that must be met to deal with the indeterminate nature of event-driven control.

There is clearly a tension between the notions of object and event. In teaching, one has to reconciliate the interpretation of events as primitive occurrences and the interpretation of events as high level abstractions, objectifying complex interactions between collections of objects.

Background

In dealing with user actions, such as moving the mouse pointer, event objects may be employed to store the information with respect to the location of the pointer on the screen, the time the motion took, whether a mouse button was pressed etcetera. There are many toolkits that allow for the use of callback functions, which free the programmer from writing an explicit event dispatch loop. Instead of callback functions, however, handler (callback) objects may be used [DejaVu]. Handler (callback) objects have as an advantage over callback functions that (references to) resources that must be accessible when dealing with the event may be stored in the handler object itself. (Consequently, the casting of client data and the use of static or global variables is no longer needed.)

As described for example in [Henderson], events may also be employed to characterize high-level interactions with the application, which may either result from user actions (such as selecting a menu item), from calling a function in the application programmer interface, or from scheduling the event in a simulation run. (Actually in this interpretation, events merge the occurrence of primitive events and the activation of handler objects.)

Basic metaphor

Events objectify occurrences and the (system) behavior that results from such occurrences. Again, daily life abounds with situations which are beyond (direct) control, and which require an attitude of "wait, see and react".

A common feature of systems employing events is the inversion of control. The inversion of control is what distinguishes object-oriented frameworks from (ordinary) class libraries which are passive, relying on programmer-defined (external) control flow. We may call the inversion of control underlying events (and a number of patterns) the "don't call us, we call you" principle. Needless to say, it only works when there is an agreement on the protocol of interaction!

A distinction must be made between the information concerning the event and the actions that are performed to respond to the event. In application-defined events these two aspects usually coincide. In window applications, event-related information must be explicitly passed to the (handler) callback object.

Both application-defined events and event/handler objects may be regarded as primitives at the time of invocation. Once created, the functionality of events and handler objects is fixed, although their actual behavior may depend on dynamically changing circumstances.

Realization

Given a facility to define callback functions to which client data can be passed, handler (callback) objects may be easily employed by defining a fixed (handler callback) function that invokes some member function of the handler object (which is passed as client data). Event-related information can be obtained from within the handler object itself.

Application-defined object classes must be derived from an abstract event-class, for which a standard method is defined to activate or invoke the event. In addition, the event class may provide a facility to declare dependencies between events. To enable actual simulations the system must provide a scheduler and possibly facilities to randomize the activation times of events [DejaVu].

Comments

In our treatment of events we unify traditionally distinct interpretations of the notion of event (that is, events representing user actions, events defining application-defined interactions with the system, and events that can be explicitly scheduled). However, these various notions of events have in common that they objectify behavior of arbitrary complexity in a way that allows for indeterminate control. In particular, when activated, events may be regarded as primitives.

introduction teaching contracts patterns events examples foundations conclusions references