The object/event duality

One of the major problems in software engineering that must be resolved for each software development project is to obtain a proper modular decomposition of a system. Object orientation, supporting a component-based approach, is a big step, as it provides the mechanisms necessary to address this problem. However, as argued in our historical aside below, it provides only part of the solution. What is still lacking, somehow, is a proper solution to the problem of characterizing the interaction between collections of objects. A (partial) solution to this problem, however, is suggested by employing events to define the interaction between objects. See also sections systems and events. In the OOPSLA'92 panel, with the title The heresy of event-orientation in a world of objects, several speakers observed a discomfort with respect to the notion of events in the object-oriented community. A reason for this discomfort is the tension between objects and events, a tension which is known as the object/event duality. Traditionally, events are actions operating on passive entities, whereas objects are meant explicitly to integrate data and operations thereupon.

Events -- actions involving objects


slide: Objects and events

Why not abolish events altogether, then? The title of the panel, obviously indicates the reluctance of many software developers to part from events in modeling the behavior of (object-oriented) systems. This reluctance may be explained (partly) as a drive for continuity, a natural opposition to throwing away techniques that have proven to be beneficial in the past. (This is probably also the reason that event-based techniques also occur in modernized, read object-oriented, versions of structured development methods, as examined in section methods.) However, there are also strong arguments in favor of the position that events (which are extraneous to objects) are an essential ingredient (in modeling the behavior) of object-oriented systems. See also sections perspectives and events. The notion of events may play a role in requirements analysis, as well as in design and implementation. As for requirements analysis, the first author of  [Jacobs92], who was one of the speakers of the panel, observed that use case analysis (which is part of Objectory) in essence comes down to listing all possible events occurring in the interaction with the user. Such an analysis specifies the functional properties of a system whose behavior will be realized by an appropriate object model. As for design, we may note that events may be used to characterize the interaction between objects in a generic fashion. In section events, we discussed an example demonstrating the use of event-driven control as a means to manage the complexity of object compositions. Event-driven control also underlies the implementation of many window-based systems. An event coming from the user or window manager may trigger an action that is defined as a callback function associated with the event. See slide 11-events. In the next chapter we will look in more detail at the way in which control is handled by objects in response to events occurring in a window-based system.

Some history

In sections what and abstraction, we have sketched the history underlying the development of object-oriented programming languages, as directed towards increasingly powerful abstractions and constructs for developing reliable software. }
\setlength{\unitlength}{0.0050in}% \begin{picture}(135,298)(40,485) \thicklines \put(175,565){\vector( 0,-1){ 60}} \put(150,660){\vector( 0,-1){ 55}} \put(100,760){\vector( 0,-1){ 65}} \put(150,485){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Ravioli code}} \put( 85,580){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Object Oriented Programming}} \put( 40,770){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Spaghetti code}} \put( 85,670){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Structured Programming}} \end{picture}
slide: Some history

In short, we may characterize the genesis of structured programming as the outcome of the war against the goto and its associated spaghetti code. The subsequent development of object-oriented programming may then be understood as the realization that data is as important as control. Ironically, the disciplined use of encapsulation and inheritance (as mechanisms for data abstraction) may lead to another proliferation of control, threatening the integrity and manageability of object-oriented code. One part of the control problem of object orientation is known as ravioli code, which expresses depictively the existence of a large number of (small) objects with well-defined interfaces, which interact in a complex way. See slide 11-history. The other part of the control problem is known as the yo-yo problem, which characterizes the difficulty of locating control in a class hierarchy with virtual functions. These problems are notoriously hard to solve, yet lie at the core of good library design. As a partial solution to the problem of structuring the interaction between objects we have discussed the notion of events to define generic interactions. However, essential to a successful component-based approach, we need sufficiently high-level components to start with.