4.1. Events Drive Object Collaboration

At its simplest, the process of OO software development involves the following:

• Properly establishing the functional requirements for, and overall mission of, an application

• Designing the appropriate classes necessary to fulfill the requirements and mission

• Instantiating the classes to create objects

• Setting the objects in motion through internal and/or external triggering events

Think of an anthill: at first glance, you may see no apparent activity taking place. But if you drop an ice cream cone nearby, a flurry of activity suddenly begins as ants rush around to gather up the "goodies," as well as to repair any damage that may have been caused if you dropped the ice cream cone too close to the anthill!

Within an OO application (the "anthill"), the objects ("ants") may be set in motion by an external event such as

• The click of a button on the Student Registration System (SRS) graphical user interface (GUI), indicating a student's desire to register for a particular course.

• The receipt of information from some other automated system, such as when the SRS receives a list of all students who have paid their tuition from the university's billing system.

As soon as such a triggering event has been noted by an OO system, the appropriate objects react, performing services themselves or requesting services of other objects in chain-reaction fashion, until some overall system goal has been accomplished. For example, the request to register for a course as made by a student user via the SRS application's GUI may involve the collaboration of many different objects (see Figure 4-1):

• A Student object (an abstraction of the real student user)

• A DegreeProgram object to ensure that the requested course is truly required for the student to graduate

• The appropriate Course object to make sure that there is a seat available in the course for the student

• A Classroom object representing the room in which the course will be meeting, to verify its seating capacity

• A Transcript object—specifically, the Transcript of the Student of interest—to ensure that the student has met all prerequisites for the course

Figure 4.1. SRS objects must collaborate to accomplish the overall SRS mission.

Meanwhile, the user of the SRS is blissfully ignorant of all the objects that are "scurrying around" behind the scenes to accomplish the student's goal; the student merely fills in a few fields and clicks a button on the SRS GUI and a few moments later sees a message that either confirms or rejects the student's registration request.

Once the ultimate goal of an event chain has been achieved (for example, registering a student for a course), an application's objects may effectively become idle, and may remain so until the next such triggering event occurs. An OO application is in some ways similar to a game of billiards: hit the cue ball with your cue stick, and it (hopefully!) hits another ball, which might collide with three other balls, and so on. Eventually, however, all balls will come to a standstill until the cue ball is hit again.