Page 2
Representation as Instruction
Java is an object-oriented programming language. This means that is
uses objects to write instructions. But an object is not an instruction, is
it? Well, not really. It's more correct to say that an object is a desciption
of something, but that description can include instructions. Please reread
these last sentences until it begins to settle in. This is very very very very
very very very very very very important!
Imagine, for a moment, that you wanted to instruct the computer to move
pacman to the right. The question is, what do we need before we can move pacman
to the right? Well, we need a pacman, of cousrse! But it doesn't stop there. We
also need a playing board. That is, we need something that encapsulates where
walls are. Then, we need some higher being that knows about our pacman and our
playing board, and can deduce whether or not it is even possible to move
pacman to the right. Then, and only then, we can tell our computer to
move pacman to the right.
What this means, then, is that in CS302 our primary concern is not
computation, but instead representation. Our source files will not so much
contain sequential instructions as they will object descriptions. For example,
in the pacman example above, we would have one source file dedicated to
describing a pacman. This source file would probably need to include at least
its current location. Another source file would be dedicated to describing the
playingboard. It would have a listing of every wall, and the locations of each
of them. Then, a third source file would contain just a few instructions that
makes the pacman object and the board object from their descriptions, checks
to see whether or not the space to the right of pacman is a wall, and if not it
physically changes pacman's location to be one square to the right.
This is what a typical JAVA program will look like. There will be several
source files dedicated to descriptions of the world in which we wish to perform
computation, and then one or two source files that will create objects out
of those descriptions and play around with them to actually perform the
computation. One of these files is, of course, the Main file.
Classes and Objects
We have seen, in the pacman example above, that our approach in this course
will be first write descriptions of objects, and then to actually create them
and use them, in computation. The advantage of this approach is that we can
write out a single description of a ghost object, and then create four ghosts,
Blinky, Pinky, Inky and Clyde out of the same ghost object description. We will
call the actual objects either objects or instances and we will
call the object decriptions classes. Furthermore, we will define the
relation between an object and its class the instanceof relation. Here,
Blinky is an "instance of" the Ghost class.
Object Categories
It is useful at this point to consider the variability of classes. For
example, the Math class (found in the java.lang package) is simply a
bunch of available mathematical constants and functions for you to use, such as
the value PI and the absolute value function. This class just sits around and
lets other parts of the program use its constants and functions. But the main
class in the pacman program will be responsible for creating pacman objects and
board objects and ghost objects, and interacting with them. The pacman and
ghost classes are also different. They have values (such as their
locations) and possibly functions (such as moveLeft and moveRight), but they
are not in control. They are part of the representation of the problem. Other
classes and objects will change their locations or instruct them to move left
or right. To help accommodate these differences in behavior, there are several
object categories.
Controller objects are in charge of the computation. They usually
create objects from their class descriptions to simulate the world, and then
operate on them to carry out the computation.
Application Logic objects represent the world in which the
computation will occur. For example, the pacman, playing board, and ghost
objects are all direct representations of specific parts of a pacman game
scenario. Most of your classes will be application logic classes.
User Interface objects deal with communicating with the user while
the program is running. For example, if you were actually playing Pacman, then
a joystick object would be a user interface object. Objects involved in getting
your input or displaying results back to you are all user interface
objects.
Storage objects deal with external files, and we won't cover them
until later in the course. They are involved with reading information from or
writing information to different files.
Single Task Object Principle
When designing classes and objects for a program, it is a good idea to
separate out elements of the problem or solution that seem separate to you. For
example, while the pacman game has a pacman and four ghosts, we should not
create a PacmanAndFourGhosts class. It just doesn't make sense to lump them
together like that. Moreover, we will tie oursleves up in knots trying to
distinguish the pacman from the four ghosts. We obviously can't have one
single location for all of them! Far better to identify that there should be a
Pacman class out of which we will make exactly one pacman object, and a Ghost
class out of which we will make exactly four different ghost objects.
The Single Task Object Principle (somethimes the STO
Principle) dictates that we should design our classes with very specific and
unique tasks in mind. In the above example, the STO Principle dictates that we
should separate the Pacman class from the Ghost class, the Ghost class from the
PlayingBoard class, and the PlayingBoard class from the controller object that
will operate on them.
Class and Object Members
We are now ready to actually describe classes and objects. Remember that
you alone control the descriptions. In this way, the descriptions will reflect
exactly what you write, and differences and similarities will coincide exaclty
with the degree of similarity of their description.
When describing classes and objects, you may give them data members,
which are information that they carry with them and always know about, and you
may give them method members, which are actions that they may then be
asked to perform. (Note that it is possible to give them information that they
don't need, or actions that no one will ask them to perform, but this would be
patently useless).
Data members have the option of being a constant ( being
final) or a variable that is able to change. What if the pacman's
location data was final? Then pacman would be stuck in the same location the
entire game. But the playingBoard may want to keep the location of its walls
final.
Now we need to consider who has the ability, besides the class/object
itself, to know about these data members and to call these method members to
action. This is known in object-oriented programming as visibility. When
describing members, you must choose to associate with them a specific
visibility. This visbility is usually either public or
private. Public visibility means that any other class or object has
access to that member. For instance, if the pacman's location data was public,
then the ghosts would be able to look at it. Even worse, if the pacman's
moveLeft method was public, then the ghosts could move pacman left any time
they wanted! However if the location data and moveLeft method were private,
then no other class or object would be able to move pacman left except the
pacman itself.
The last choice to make is whether or not to associate the member with the
class, or associate a new member with each specific object. The word
static is the JAVA word that means that a member is associated with the
class. Being associated with the class, or static, means that all objects share
that exact same copy of the data or method, and that it cannot refer to any
one specific object. For instance, if any class included a data member for the
time of day, then that might be a good data member to make static, since there
is only one time of day that eveyone shares, and the time of day doesn't depend
upon the object. A data member such a name, however, should not be made
static. Everyone should be able to have a different name. A name is something
that should be associated with each object separately, not commonly
shared.
For more information on the different types of members, see this page.