Page 3
Class and Object Members
When describing classes (and therefore the 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. These data members can include other
objects. For example, a rollerskate class is a class that has a color, a
foot size, and four wheel objects. Among its actions are to skateForward
and to stopSkating.
These (data and method) members of classes (and objects) have many
properties, aside from being members of the class or object. All of these
properties must be design decisions on your part, and they should reflect
both what you want to represent, and how the computation will take place.
Data members have the option of being a constant ( being
final) or a variable that is able to change. What if the roller
skate's location data was final? Then the person in that skate would be stuck
in the same place the entire time. However, the color of the roller
skate, since it is not very likely at all to change, should be made
final.
Now we need to decide 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.
A large part of the computation will deal with object interaction. This
means that our roller skate could have four wheel objects. This would
illustrate the belongs to relation, because the wheels on the skate are
said to "belong to" that skate. The wheels, as one memeber, could have a method
called spin. The interaction between the skate and the wheel would be that the
skate's skateForward method would simply call the spin method on every wheel
that it owns. But this presents a problem. First we have to garuntee ourselves
that a skate object has the ability to call a wheel's spin method. This is
known in object-oriented programming as visibility. The visibility
of a member of a class (or object) dictates what other classes besides
itself are able to call that method or look at that data.
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 skate's location data was public,
then any other class or object could take that location and change it to
wherever they so desired, and whenever they so desired. If the location
was private, then no one except skate objects (or the skate class) would
be able to change the skate's location object.
For a summary on the different types of members and the fine differences
between them, see this page.
Inheritance
So far, we've covered two types of relation. The relation between
a class and one of its objects, and the relation between one object and another
object that the first one "has" in it among its data members. We can also
describe a heirarchical relation between classes called the "is
a" relation. For example, all people named Kristen have names that begin with
the character K. We could define two classes here: 1) The class of all people
named Kristen, and the class of all people whose name begin with the character
K. Notice that the "is a" relation only works in one direction. Kyle, whose
name clearly begins with the character K, is not named Kristen.
The "is a" relation is known in object-oriented programming as
inheritance. The more general class is called the superclass or
sometimes the parent class. The more specific class is called the
subclass or sometimes the child class. Extending the family
analogy, the parent class of a parent class is more generally an
ancestor class, and the converse terminology here is a descendent
class.
Notice that in our class descriptions we can save time and space when we
are given classes where one inherits from the other, since we know that the
child class has in it at least the members of the parent class. For example,
the class Square is a subclass of the class Rectangle. When we are are
describing the Square class, we don't have to say again that it has four
sides. Hopefully, we already know this since a square object "is a" rectangle
object and rectangles all have four sides.
As a final note on inheritance, JAVA stipulates that any class may inherit
from at most one other class. The alternative to this is called multiple
inheritance, and is used in other laguages such as C++.
Diagrams
In this course, we will be studying (roughly) three types of diagrams. They
are, class/inheritance diagrams, object/memory/state diagrams,
and control flow diagrams. A class/inheritance diagram shows the class
descriptions, all of the class members (and whether they are public, private,
static, or final), and the inheritance relations. An object/memory/state
diagram shows what objects are currently in use by the computer and the values
of their data members. These diagrams describe what your representative model
"looks like" during computation. Control Flow diagrams show the decision
process and the flow of computation in your program, and will be covered later
in the course.
Please follow this digrams link to see
how to diagram class/inheritance diagrams as well as object/memory/state
diagrams