Chapter 10: Event-Driven Programming

Overview

Sometimes it is useful to think of applications in terms of events and how best to handle them, rather than look at that application's architectural design from a traditional object-oriented perspective. That's not to say that we must discard an OOP approach altogether to implement event handling, rather that we build classes around the events relevant to the application. This approach is rather radical, but for many applications you may find that it gives you a massively powerful mechanism for approaching the software architecture of the whole project.

Events occur pretty much all the time, and some of the best examples of event-driven programming are the applications we use every day to manage e-mail or write text. For the end-user, Windows-based programs, event handling is of paramount importance. This is because these applications are designed to lurk around until the user does something and then react accordingly. Of course, the same is now true for many Web-based applications. Anything with a GUI is a likely candidate for the event-driven programming paradigm.

Nearly all actions taken by a user, and even those taken by the applications themselves, can be thought of as an event. A rather contrived example of an event not initiated by a user is your machine's clock. If you wanted to create an application that performed various actions depending on the time, you could capture certain changes in time as an event, and bundle it off to a piece of code that deals with it accordingly.

Whatever needs to be done, applications have various ways to implement a solution, and PHP5 is no different in this regard. There is, of course, no new extension or library to deal with events, because the way we deal with them is more about how we "think" about designing an application rather than how we actually implement it. In other words, they need no special underlying technology. Let's take a look at one way to handle events in PHP.