in.
<P>
<I>Class data</I> is data that is maintained on a class-wide basis,
independent of any objects that have been created.
<P>
There is only one instance of class data in memory no matter how
many objects are created from the class. Class data is typically
used to store common information that needs to be shared among
all instances of a class. A common example of class data is a
count of how many instantiated objects exist of a particular class.
When a new object is created, the count is incremented, and when
an existing object is destroyed, the count is decremented.
<P>
Objects provide the benefits of modularity and information hiding,
whereas classes provide the benefit of reusability. Just as the
builder reuses the blueprint for a house, the software developer
reuses the class for an object. Software programmers can use a
class over and over again to create many objects. Each of these
objects gets its own data but shares a single method implementation.
<H3><A NAME="Encapsulation"><B>Encapsulation</B></A></H3>
<P>
<I>Encapsulation</I> is the process of packaging an object's data
together with its methods.
<P>
A powerful benefit of encapsulation is the hiding of implementation
details from other objects. This means that the internal portion
of an object has more limited visibility than the external portion.
<P>
The external portion of an object is often referred to as the
object's interface, because it acts as the object's interface
to the rest of the program. Because other objects must communicate
with the object only through its interface, the internal portion
of the object is protected from outside tampering. And because
an outside program has no access to the internal implementation
of an object, the internal implementation can change at any time
without affecting other parts of the program.
<P>
Encapsulation provides two primary benefits to programmers: 
<UL>
<LI>Implementation hiding
<LI>Modularity
</UL>
<P>
<I>Implementation hiding</I> refers to the protection of the internal
implementation of an object.
<P>
An object is composed of a public interface and a private section
that can be a combination of internal data and methods. The internal
data and methods are the sections of the object that can't be
accessed from outside the object. The primary benefit is that
these sections can change without affecting programs that use
the object.
<P>
<I>Modularity</I> means that an object can be maintained independently
of other objects.
<P>
Because the source code for the internal sections of an object
is maintained separately from the interface, you are free to make
modifications and feel confident that your object won't cause
problems. This makes it easier to distribute objects throughout
a system, which is a crucial point when it comes to Java and the
Internet.
<H3><A NAME="Messages"><B>Messages</B></A></H3>
<P>
An object acting alone is rarely very useful; most objects require
other objects to really do anything. For example, the car object
is pretty useless by itself with no other interaction. Add a driver
object, however, and things get more interesting! Knowing this,
it's pretty clear that objects need some type of communication
mechanism in order to interact with each other.
<P>
Software objects interact and communicate with each other via
<I>messages</I>. When the driver object wants the car object to
accelerate, it sends a message to the car object. If you want
to think of messages more literally, think of two people as objects.
If one person wants the other person to come closer, they send
the other person a message. More accurately, one might say to
the other person &quot;come here, please.&quot; This is a message
in a very literal sense. Software messages are a little different
in form, but not in theory; they tell an object what to do. In
Java, the act of sending an object a message is actually carried
out by calling a method of the object. In other words, methods
are the mechanism through which messages are sent to objects in
the Java environment.
<P>
Many times, the receiving object needs more information along
with a message so that it knows exactly what to do. When the driver
tells the car to accelerate, the car must know by how much. This
information is passed along with the message as message <I>parameters</I>.
<P>
From this discussion, you can see that messages consist of three
things.
<OL>
<LI>The object to receive the message (car)
<LI>The name of the action to perform (accelerate)
<LI>Any parameters the method requires (15 mph)
</OL>
<P>
These three components are sufficient information to fully describe
a message for an object. Any interaction with an object is handled
by passing a message. This means that objects anywhere in a system
can communicate with other objects solely through messages.
<P>
Just so you don't get confused, understand that &quot;message
passing&quot; is another way of saying &quot;method calling.&quot;
When an object sends another object a message, it is really just
calling a method of that object. The message parameters are actually
the parameters to a method. In object-oriented programming, messages
and methods are synonymous.
<P>
Because everything that an object can do is expressed through
its methods (interface), message passing supports all possible
interactions between objects. In fact, interfaces enable objects
to send messages to and receive messages from each other even
if they reside in different locations on a network. Objects in
this scenario are referred to as <I>distributed objects</I>. Java
is specifically designed to support distributed objects.
<H3><A NAME="Inheritance"><B>Inheritance</B></A></H3>
<P>
What happens if you want an object that is very similar to one
you already have, but with a few extra characteristics? You just
derive a new class based on the class of the similar object.
<P>
<I>Inheritance</I> is the process of creating a new class with
the characteristics of an existing class, along with additional
characteristics unique to the new class.
<P>
Inheritance provides a powerful and natural mechanism for organizing
and structuring programs.
<P>
So far, the discussion of classes has been limited to the data
and methods that make up a class. Based on this understanding,
you build all classes from scratch by defining all of the data
and all of the associated methods. Inheritance provides a means
to create classes based on other classes. When a class is based
on another class, it inherits all of the properties of that class,
including the data and methods for the class. The class doing
the inheriting is referred to as the <I>subclass</I> (child class)
and the class providing the information to inherit is referred
to as the <I>superclass</I> (parent class).
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Child classes are sometimes referred to as <I>descendants</I>, and parent classes are sometimes referred to as <I>ancestors</I>. The family tree analogy works quite well for describing inheritance.
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Using the car example, gas-powered cars and cars powered by electricity
can be child classes inherited from the car class. Both new car
classes share common &quot;car&quot; characteristics, but they
also have a few characteristics of their own. The gas car would
have a fuel tank and a gas cap, and the electric car might have
a battery and a plug for recharging. Each subclass inherits state
information (in the form of variable declarations) from the superclass.
Figure 3.3 shows the car parent class with the gas and electric
car child classes.
<P>
<A HREF="f3-3.gif" ><B>Figure 3.3 : </B><I>Inherited car objects.</I></A>
<P>
The real power of inheritance is the ability to inherit properties
and add new ones; subclasses can have variables and methods in
addition to the ones they inherit from the superclass. Remember,
the electric car has an additional battery and a recharging plug.
Subclasses also have the capability to override inherited methods
and provide different implementations for them. For example, the
gas car would probably be able to go much faster than the electric
car. The accelerate method for the gas car could reflect this
difference.
<P>
Class inheritance is designed to allow as much flexibility as
possible. You can create inheritance trees as deep as necessary
to carry out your design. An inheritance tree, or class hierarchy,
looks much like a family tree; it shows the relationships between
classes. Unlike a family tree, the classes in an inheritance tree
get more specific as you move down the tree. The car classes in
Figure 3.3 are a good example of an inheritance tree.
<P>
By using inheritance, you've learned how subclasses can allow
specialized data and methods in addition to the common ones provided
by the superclass. This enables programmers to reuse the code
in the superclass many times, thus saving extra coding effort
and therefore eliminating potential bugs.
<P>
One final point to make in regard to inheritance: It is possible
and sometimes useful to create superclasses that act purely as
templates for more usable subclasses. In this situation, the superclass
serves as nothing more than an abstraction for the common class
functionality shared by the subclasses. For this reason, these
types of superclasses are referred to as <I>abstract classes</I>.
An abstract class cannot be instantiated, meaning that no objects
can be created from an abstract class. An abstract class cannot
be instantiated because parts of it have been specifically left
unimplemented. More specifically, these parts are made up of methods
that have yet to be implemented, which are referred to as abstract
methods.
<P>
Using the car example once more, the accelerate method really
can't be defined until the car's acceleration capabilities are
known. Of course, how a car accelerates is determined by the type
of engine it has. Because the engine type is unknown in the car
superclass, the accelerate method could be defined but left unimplemented,
which would make both the accelerate method and the car superclass
abstract. Then the gas and electric car child classes would implement
the accelerate method to reflect the acceleration capabilities
of their respective engines or motors.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
The discussion of inheritance naturally leads to the concept of <I>polymorphism</I>, which is the notion of an object having different forms. Using polymorphism, it is possible to have objects with similar interfaces but different responses to method 
calls. In this way, an object is able to maintain its original interface within a program while taking on a different form.
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<H2><A NAME="OOPandGames"><B><FONT SIZE=5 COLOR=#FF0000>OOP and
Games</FONT></B></A></H2>
<P>
So far, I've talked a lot about the general programming advantages
of using objects to simplify complex programming tasks, but I
haven't talked too much about how they specifically apply to games.
To understand how you can benefit from OOP design methods as a
game pro-grammer, you must first take a closer look at what a
game really is.
<P>
Think of a game as a type of abstract simulation. If you think
about most of the games you've seen or played, it's almost impossible
to come up with one that isn't simulating something. All the adventure
games and sports games, and even the far-out space games, are
modeling some type of objects present in the real world (maybe
not <I>our</I> world, but <I>some</I> world nevertheless). Knowing
that games are models of worlds, you can make the connection that
most of the things (landscapes, creatures, and so on) in games
correspond to things in these worlds. And as soon as you can organize
a game into a collection of &quot;things,&quot; you can apply
OOP techniques to the design. This is possible because things
can be translated easily into objects in an OOP environment.
<P>
Look at an OOP design of a simple adventure game as an example.
In this hypothetical adventure game, the player controls a character
around a fantasy world and fights creatures, collects treasure,
and so on. You can model all the different aspects of the game
as objects by creating a hierarchy of classes. After you design
the classes, you create them and let them interact with each other
just as objects do in real life.
<P>
The world itself probably would be the first class you design.
The world class would contain information such as its map and
images that represent a graphical visualization of the map. The
world class also would contain information such as the current
time and weather. All other classes in the game would derive from
a positional class containing coordinate information specifying
where in the world the objects are located. These coordinates
would specify the location of objects on the world map.
<P>