chap12.htm

Since the field of object oriented programming is probably new to you, you will find that there is a

and eight methods to handle the variables. Instead of a detailed description
of each variable and method, we will only give a brief overview of the
class.

<P>Only one object of this class is declared named <B>flight_info</B> in
line 22 of the main program named FLYAWAY.CPP. The constructor initializes
the flight possibilities, and the method named <B>shuffle_gates()</B> shuffles
all gates around if the player arrives at his correct gate without reading
the monitor in the waiting area. Once the monitor in the waiting area is
read, the <B>flights_frozen</B> variable is made TRUE. Likewise, the players
destination is changed during every move by the method named <B>shuffle_flights()
</B>until the player reads his ticket invoking the method named l<B>ist_actual_destination()</B>.

<P>This class contains the methods to list the data seen on the monitor,
as well as the data seen when invoking the command <B>look </B>at one of
the gates. Finally, this class contains the method named <B>check_flight()</B>
which searches through the list of requirements to see if the player has
completed all requirements to successfully reach the final destination
for his vacation.

<P>You will notice that several of the location objects were required to
be available within this code and are listed as <B>extern </B>in lines
12 through 21 of the implementation of the class. The only other thing
to point out is the rest room requirement prior to boarding the flight.
Line 28 is where the global variable is defined and initialized, then in
line 77 it is set TRUE if the current location is the rest room, since
this is called once during each player move. Finally, the state of this
variable is checked in line 230 of this file and the appropriate action
taken. You will note that the main program is not aware that the rest room
variable exists or that anything happens as a result of this variable.
In addition to information hiding, we may coin a new term, something like
"Information Ignorance", since the main program did not even need to be
aware that there was a requirement to visit the rest room.

<P>Even though this is a relatively large and complex class, it is well
commented so no further information will be given concerning the implementation.

<P><B>THE MOST USED CLASS - location</B>

<P>Example program ------> <B><A HREF="LOCATION.H">LOCATION.H</A></B>

<P>The file named LOCATION.H is the header file for the class named <B>location</B>.
It is the class that controls all of the moves from location to location.

<P>This class is a bit unusual in that most of the stored data is in the
form of pointers to the various entities. The first four are the locations
to which we will go if we move in one of the four directions from the current
location. You will note that they are pointers to those four locations.
Next we have pointers to two different character strings associated with
this room. Finally in line 22, we declare the object named <B>list_of_items
</B>which is an object of class <B>items </B>defined earlier. Note that
this is an embedded class, a class embedded within the <B>location </B>class.
It is not a parent class which we are inheriting something from. In fact
we are instantiating an object of class <B>items </B>for use within the
room since the room is allowed to store any combination of the four items
contained in the class named <B>items</B>.

<P>There is no constructor used with this class since we choose to initialize
the locations one by one. The method named <B>init()</B> has 6 variable
parameters, all of which are pointers, associated with it which it uses
to initialize the first six variables of this object. The last variable,
an object of class <B>items</B>, is initialized through use of the constructor
associated with its class. Referring to lines 40 through 171 of the implementation
for the <B>map </B>class, you will find all of the initialization code
for the 19 objects of class <B>location</B>. If you drew a map when you
played the game, you will see the interconnections between the various
locations embedded in the initialization statements. Notice there is no
way to get back to the car from the passenger drop off area, because presumably
the car leaves when you get out of it.

<P>The next method, named <B>move()</B>, returns a pointer to the new location
if a move was legal, otherwise it returns a NULL value. The observant student
will also notice that there are special cases involved with getting out
of the snack bar and getting through security. These are located here because
they are part of the move logic. If you played the game to the complete
conclusion, you surely had trouble with at least one of these situations.

<P>The rest of the methods in this class should be self explanatory and
will not be discussed any further.

<P><B>THE LOCATION MESSAGES</B>

<P>Example program ------><B> <A HREF="MESSAGE.TXT">MESSAGE.TXT</A></B>

<P>Examine the file named MESSAGE.TXT for a complete listing of the messages
output to the monitor when each location was entered. You will also find
the text for each of the messages output in response to a <B>look </B>command
in this file. These were put into a separate file only for the purpose
of reducing the size of the <B>map </B>class implementation file. It does
not reduce the compile time since these messages are not separately compiled.
They are included into the file and compiled each time the map file MAP.CPP
is compiled. You will note that a few of the messages have no text at all,
only the empty quote marks, but are included in order to have something
for the initialization code to work with.

<P>Three other messages are stored here for convenience in lines 5 through
40. Their use and meaning should be self-evident.

<P><B>THE MAIN PROGRAM</B>

<P>Example program ------> <B><A HREF="FLYAWAY.CPP">FLYAWAY.CPP</A></B>

<P>We finally reach the main program, the one that actually does the top
level control. Examine the program named FLYAWAY.CPP and we will look at
some of its interesting characteristics.

<P>Beginning with the <B>main()</B> entry point itself, we see that following
a call to <B>airport.initialize()</B>, we enter a single <B>do while</B>
loop which terminates when the player enters the word <B>quit </B>or when
the verb <B>quit </B>comes up some other way. There are other ways to set
the verb to <B>quit </B>because it is generated internally in some cases
such as at end of game.

<P>The loop itself consists of 5 method calls. First we call the function
named <B>input_words.get_command()</B> to get the players input command
in line 30. Next we send two messages to the object named <B>flight_info</B>
to shuffle the flights and gates if the proper actions have not been performed,
then we call <B>airport.perform_action()</B> which we will describe in
a few paragraphs. Finally, we send a messages to the object named <B>flight_info</B>
to check if the player has reached one of the gates. Remember that within
most of the methods we perform checks to see if we need to do the thing
requested in the message, then either perform the action or simply return
to the caller or message sender.

<P><B>THE WORKING METHOD</B>

<P>Example program ------> <B><A HREF="MAP.H">MAP.H</A></B>

<P>The only function we have not mentioned yet is the one that does most
of the interesting work, the function named <B>perform_action()</B> which
begins in line 183 of the MAP.CPP file. This function looks at the <B>verb
</B>and <B>noun</B>, if there is one, and causes the correct action to
be performed. Because of the way we packaged all of the other routines,
this function is a snap to implement and to study. If you go through each
of the <B>else if </B>clauses in this function, you will have no trouble
understanding what action is taken for each of the input commands. You
will notice that many of the actions have conditional clauses before the
action is taken. For example, it is illegal to buy <B>candy </B>unless
the player has <B>money</B>, the location has <B>candy</B>, and the location
must be the <B>snack_bar</B> according to the rules of the game.

<P>Finally, at the end of this method in line 277, we have the default
case if nothing else was accomplished. It is assumed that there was something
funny requested such as a request to get a monitor. Both of these are legal
words but they make no sense together.

<P><B>FINAL COMMENTS ON FLYAWAY</B>

<P>Now that you have played the game for awhile and studied the game in
detail, you should have an appreciation for how this game can be written.
Of course, it could be written in any of several thousand different ways
of packaging and definition. This has been only one of the ways.

<P>Because the student may be left with the sinking feeling that this method
simply fell out of the sky or was arrived at in some other esoteric way,
it would only be fair to point out that several earlier attempts at outlining
this project were attempted and rejected prior to this arrangement. Also,
when this tutorial was being updated from version 2.0 to 2.2, the entire
program was restructured. In version 2.0 and prior versions, about 50%
of the code was in classes, but due to additional programming experience,
about 98% of the flyaway program is now encapsulated in classes.

<P>Object oriented programming requires the same forethought as non-object
oriented programming, but the object oriented compiler will help you in
the coding and debugging phase since the compiler will find and flag many
of the oversight errors we are so good at introducing into our code. It
was observed during the coding and debugging phase of this project that
in nearly every case, when the program finally got through the compiler,
the program would actually run without bombing out the system. This is
not always the case using any standard procedural programming language.

<P><B>YOUR PROGRAMMING PROJECT</B>

<P>This programming assignment is intended to give you a little experience
in working with a relatively large project as opposed to the very small
programs we have been working with in this tutorial.

<P>Add a suitcase to the game, to be found in the car at arrival, and which
must be checked in at the ticket counter prior to attempting to get through
airport security. This will not be trivial since several classes will be
affected. Some of the operations you will have to do are listed below.
<OL>
<LI>
Add the noun "suitcase" and the verb "check" to the word list. Of course,
they must be entered at the right place in the list.</LI>

<LI>
Add the suitcase to the <B>items </B>class, including additional code to
each of its methods.</LI>

<LI>
Initialize the items at location <B>your_car</B> to include the suitcase.</LI>

<LI>
Add an additional check when passing through security to check that the
player is not carrying the suitcase. You can add any sort of penalty desired,
including death by firing squad for attempting such an obviously crooked
deed.</LI>

<LI>
You will need to add a check when the player finally gets on his correct
airplane to see that he checked his suitcase. If he did not, you could
output any desired text indicating stupidity or forgetfulness.</LI>
</OL>
Since I have not actually added the suitcase to the game and tested it,
I am not sure that this is all that will be required, but it should be
the majority of effort required. The bottom line of this effort is that
if you understand this program enough to perform this modification, you
have a good understanding of how the program works and how objects work
together to perform a task.

<P>Once you understand this program, you should define a programming project
for yourself that will use object oriented programming techniques and begin
designing and programming it. The best way to learn to use OOP is to actually
use it.

<P>Good luck in your OOP endeavors.

<P><A HREF="cpplist.htm">Return to Table of Contents</A>
</BODY>
</HTML>