| A piece of software is considered interactive if it consumes input and produces output throughout its execution, in contrast to non-interactive software which takes its input at program initialization and produces its output at program termination. Interactive software includes network servers, user interface applications, and computer games, and makes up the majority of user-facing software. The most common approach to implementing interactive components within modern languages is an event-driven style, which creates components that respond to events, possibly modifying their internal state as a result. Despite its popularity, this style has several disadvantages. First, in converting interactive logic to the event-driven style, it must go through an inversion of control, which separates the logic into many pieces. Instead of using standard control structures like while loops, control flow is implicitly defined through manipulating object fields. Second, the state design pattern, a common implementation of the event-driven style in object-oriented languages, has no mechanism to allow for extensibility, a natural desire in the pattern's object-oriented setting. Third, the event-driven style assumes that another software entity is in control of an interactive component, but many interactive components exchange control throughout their execution between themselves and their "controllers". Many implementations of the event-driven style, such as the state design pattern, do not easily allow for these exchanges of control, requiring ad-hoc solutions which defeat many of the advantages of those implementations.;We provide three solutions to these problems: The first, Responders, is a new language feature which avoids inversion of control by letting interactive logic keep a separate execution context that is suspended then resumed upon the receipt of an event. The Extensible State Machine Pattern, the second solution, is a modification of the normal state design pattern that allows state machines that implement it to be extended in several natural ways. The third solution is the Dialogue Pattern, a software pattern which naturally handles exchanges in control without needing any additional features to language in which it is implemented. We demonstrate how each of these solutions work, and validate them with our experience using them on existing software packages. |
