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
- requirements -- user actions
- design -- object compositions
- implementation -- action callbacks
- broadcasts -- talker/listener pattern
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.