|
|
At its simplest, the process of object-oriented software development involves
Properly establishing the functional requirements for, and overall mission of, an application
Designing the appropriate classes necessary to fulfill these requirements and mission
Instantiating the classes to create objects
Setting the objects in motion through 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 also 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
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 object-oriented 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.
|
|
