Section 5.5
More Details of Classes
ALTHOUGH THE BASIC IDEAS of object-oriented programming
are reasonably simple and clear, they are subtle, and they take time to get used to.
And unfortunately, beyond the basic ideas there are a lot of details. This section
covers more of those annoying details. You should not necessarily master everything
in this section the first time through, but you should read it to be aware of
what is possible. (This doesn't apply to the first subsection, below, which
you definitely need to master.) For the most part, when I need to use material from
this section later in the text, I will explain it again briefly, or I will refer you
back to this section.
Extending Existing Classes
The previous section discussed subclasses, including information
about how to program with subclasses in Java. However, that section dealt mostly
with the theory. In this section, I want to emphasize the practical matter of
Java syntax by giving an example.
In day-to-day programming, especially for programmers who are just beginning
to work with objects, subclassing is used mainly in one situation. There is
an existing class that can be adapted with a few changes or additions. This is
much more common than designing groups of classes and subclasses from scratch.
The existing class can be extended to make
a subclass. The syntax for this is
class subclass-name extends existing-class-name {
.
. // Changes and additions.
.
}
(Of course, the class can optionally be declared to be public.)
As an example, suppose you want to write a program that plays the card
game, Blackjack. You can use the Card, Hand, and Deck
classes developed in Section 3. However, a hand in the
game of Blackjack is a little different from a hand of cards in general,
since it must be possible to compute the "value" of a Blackjack hand
according to the rules of the game. The rules are as follows: The value of
a hand is obtained by adding up the values of the cards in the hand. The value
of a numeric card such as a three or a ten is its numerical value.
The value of a Jack, Queen, or King is 10. The value of an Ace can be either
1 or 11. An Ace should be counted as 11 unless doing so would put the total
value of the hand over 21. (Note that this means that the second, third, or
fourth Ace in the had will always be counted as 1.)
One way to handle this is to extend the existing Hand class
by adding a method that computes the Blackjack value of the hand. Here's
the definition of such a class:
public class BlackjackHand extends Hand {
public int getBlackjackValue() {
// Returns the value of this hand for the
// game of Blackjack.
int val; // The value computed for the hand.
boolean ace; // This will be set to true if the
// hand contains an ace.
int cards; // Number of cards in the hand.
val = 0;
ace = false;
cards = getCardCount();
for ( int i = 0; i < cards; i++ ) {
// Add the value of the i-th card in the hand.
Card card; // The i-th card;
int cardVal; // The blackjack value of the i-th card.
card = getCard(i);
cardVal = card.getValue(); // The normal value, 1 to 13.
if (cardVal > 10) {
cardVal = 10; // For a Jack, Queen, or King.
}
if (cardVal == 1) {
ace = true; // There is at least one ace.
}
val = val + cardVal;
}
// Now, val is the value of the hand, counting any ace as 1.
// If there is an ace, and if changing its value from 1 to
// 11 would leave the score less than or equal to 21,
// then do so by adding the extra 10 points to val.
if ( ace == true && val + 10 <= 21 )
val = val + 10;
return val;
} // end getBlackjackValue()
} // end class BlackjackHand
Since BlackjackHand is a subclass of Hand, an object of
type BlackjackHand contains all the instance variables and instance methods
defined in Hand, plus the new instance method getBlackjackValue().
For example, if bHand is a variable of type BlackjackHand,
then the following are all legal method calls:
bHand.getCardCount(), bHand.removeCard(0), and
bHand.getBlackjackValue().
Inherited variables and methods from the Hand class can also be used
in the definition of BlackjackHand (except for any that are declared
to be private). The statement "cards = getCardCount();"
in the above definition of getBlackjackValue() calls the instance method
getCardCount(), which was defined in the Hand class.
Extending existing classes is an easy way to build on previous work.
We'll see that many standard classes have been written specifically to
be used as the basis for making subclasses.
Interfaces
Some object-oriented programming languages, such as C++, allow
a class to extend two or more superclasses. This is
called multiple inheritance.
In the illustration below, for example, class
E is shown as having both class A and class B as direct
superclasses, while class F has three direct superclasses.
Such multiple inheritance is not allowed
in Java. The designers of Java wanted to keep the language
reasonably simple, and felt that the benefits of
multiple inheritance were not worth the cost in
increased complexity. However, Java does have a feature
that can be used to accomplish many of the same goals
as multiple inheritance: interfaces.
We've encountered the term "interface" before, in
connection with black boxes in general and subroutines in particular.
The interface of a subroutine consists of the name of the subroutine,
its return type, and the number and types of its parameters. This
is the information you need to know if you want to call the subroutine.
A subroutine also has an implementation: the block of code which
defines it and which is executed when the subroutine is called.
In Java, interface is a reserved word with an additional
meaning. An "interface" in Java consists of a set of subroutine interfaces, without
any associated implementations. A class can implement
an interface by providing an implementation for each of the
subroutines specified by the interface. Here is an example of a very simple
Java interface:
public interface Drawable {
public void draw();
}
This looks much like a class definition, except that the implementation
of the method draw() is omitted. A class that implements
the interface, Drawable, must provide an implementation
for this method. Of course, the class can also include other methods and variables.
For example,
class Line implements Drawable {
public void draw() {
. . . // do something -- presumably, draw a line
}
. . . // other methods and variables
}
While a class can extend only one other class, it can implement
any number of interfaces. In fact, a class can both extend another
class and implement one or more interfaces. So, we can have
things like
class FilledCircle extends Circle
implements Drawable, Fillable {
. . .
}
The point of all this is that, although interfaces are not classes,
they are something very similar.
An interface is very much like an abstract class, that is,
a class that can never be used for constructing objects,
but can be used as a basis for building other classes.
The subroutines in an interface are abstract methods,
which must be implemented in any concrete class that implements
the interface. And as with abstract classes, even though you
can't construct an object from an interface, you can declare a
variable whose type is given by the interface. For example,
if Drawable is an interface, and if Line
and FilledCircle are classes that implement Drawable,
then you could say:
Drawable figure; // Declare a variable of type Drawable. It can
// refer to any object that implements the
// Drawable interface.
figure = new Line(); // figure now refers to an object of class Line
figure.draw(); // calls draw() method from class Line
figure = new FilledCircle(); // Now, figure refers to an object
// of class FilledCircle.
figure.draw(); // calls draw() method from class FilledCircle
A variable of type Drawable can refer to any object
of any class that implements the Drawable interface.
A statement like figure.draw(), above, is legal because
any such class has a draw() method.
Note that a type is something
that can be used to declare variables. A type can also be used
to specify the type of a parameter in a subroutine, or the return
type of a function. In Java, a type can
be either a class, an interface, or one of the eight built-in
primitive types. These are the only possibilities.
Of these, however, only classes can be used to
construct new objects.
You are not likely to need to write your own interfaces until
you get to the point of writing fairly complex programs. However,
there are a few interfaces that are used in important ways in
Java's standard packages. You'll learn about some of these
standard interfaces in the next few chapters.
The Special Variables this and super
A static member of a class has a simple name, which can only be used inside the
class definition. For use outside the class, it has a full name
of the form class-name.simple-name.
For example, "System.out" is a static member variable with
simple name "out" in the class "System".
It's always legal to use the full name of a static member, even within the
class where it's defined. Sometimes it's even necessary, as when the simple name
of a static member variable is hidden by a local variable of the same name.
Instance variables and instance methods also have simple names that can
be used inside the class where the variable or method is defined. But a class
does not actually contain instance variables or methods, only their source code.
Actual instance variables and methods are contained in objects. To get at
an instance variable or method from outside the class definition, you need
a variable that refers to the object. Then the full name is of the
form variable-name.simple-name.
But suppose you are writing a class definition, and you want to refer to the
object that contains the instance method you are writing? Suppose you want to
use a full name for an instance variable, because its simple name is hidden
by a local variable?
Java provides a special, predefined variable named
"this" that you can use for these purposes. The variable,
this, can be used in the source code of an instance method to refer
to the object that contains the method. If x is an instance variable,
then this.x can be used as a full name for that variable.
Whenever the computer executes an instance method, it sets the variable,
this, to refer to the object that contains the method.
One common use of this is in constructors. For example:
public class Student {
private String name; // Name of the student.
public Student(String name) {
// Constructor. Create a student with specified name.
this.name = name;
}
.
. // More variables and methods.
.
}
In the constructor, the instance variable called name is hidden by
a formal parameter. However, the instance variable can still be referred to
by its full name, this.name. In the assignment statement, the
value of the formal parameter, name, is assigned to the instance
variable, this.name. This is considered to be acceptable style:
There is no need to dream up cute new names for formal parameters that are just
used to initialize instance variables. You can use the same name for the
parameter as for the instance variable.
There is another common use for this. Sometimes, when you are writing
an instance method, you need to pass the object that contains the method
to a subroutine, as an actual parameter. In that case, you can use
this as the actual parameter. For example, if you wanted
to print out a string representation of the object, you could say
"System.out.println(this);".
Java also defines another special variable, named "super",
for use in the definitions of instance methods. The variable super is for
use in a subclass. Like this, super
refers to the object that contains the method. But it's forgetful.
It forgets that the object belongs to the class you are writing,
and it remembers only that it belongs to the superclass of that
class. The point is that the class can contain additions and
modifications to the superclass. super doesn't know
about any of those additions and modifications. Let's say that
the class that you are writing contains an instance method
named doSomething(). Consider the subroutine
call statement super.doSomething(). Now, super
doesn't know anything about the doSomething() method
in the subclass. It only knows about things in the superclass,
so it tries to execute a method named doSomething()
from the superclass. If there is none -- if the doSomething()
method was an addition rather than a modification -- you'll get a syntax
error.
The reason super exists is so you can get access to
things in the superclass that are hidden
by things in the subclass. For example, super.x always refers to an instance
variable named x in the superclass. This can be useful for the following reason:
If a class contains an instance variable with the same name
as an instance variable in its superclass, then an object
of that class will actually contain two variables with the same name:
one defined as part of the class itself and one defined as part of
the superclass. The variable in the subclass does not replace
the variable of the same name in the superclass; it merely
hides it. The variable from the superclass can still be
accessed, using super.
When you write a method in a subclass that has the
same signature as a method in its superclass, the method from
the superclass is hidden in the same way. We say that
the method in the subclass overrides
the method from the superclass. Again, however, super
can be used to access the method from the superclass.
The major use of super is to override a method
with a new method that extends the behavior of the inherited
method, instead of replacing that behavior entirely. The new
method can use super to call the method from the superclass,
and then it can add additional code to provide additional
behavior. As an example, suppose you have a PairOfDice
class that includes a roll() method. Suppose that
you want a subclass, GraphicalDice, to represent a
pair of dice drawn on the computer screen. The roll()
method in the GraphicalDice method should change
the values of the dice and redraw the dice to show the new values.
The GraphicalDice class might look something like this:
public class GraphicalDice extends PairOfDice {
public void roll() {
// Roll the dice, and redraw them.
super.roll(); // Call the roll method from PairOfDice.
redraw(); // Call a method to draw the dice.
}
.
. // More stuff, including definition of redraw().
.
}
Note that this allows you to extend the behavior of the roll()
method even if you don't know how the method is implemented in the
superclass!
Here is a more complete example. The applet at the end
of Section 4.7 shows a disturbance that moves around in a mosaic of
little squares. As it moves, the squares it visits become a brighter
red. The result looks interesting, but I think it would be prettier
if the pattern were symmetric. A symmetric version of the applet
is shown at the bottom of this page. The symmetric applet can be
programmed as an easy extension of the original applet.
In the symmetric version, each time a square is brightened,
the squares that can be obtained from that one by horizontal and vertical reflection
through the center of the mosaic are also brightened.
The four red squares in the picture, for example, form
a set of such symmetrically placed squares, as do the
purple squares and the green squares. (The blue square is
at the center of the mosaic, so reflecting it doesn't produce
any other squares; it's its own reflection.)
The original applet is defined by the class RandomBrighten.
This class uses features of Java that you won't learn about for a while yet,
but the actual task of brightening a square is done by a single
method called brighten(). If row and col
are the row and column numbers of a square, then "brighten(row,col);"
increases the brightness of that square. All we need is a subclass
of RandomBrighten with a modified brighten() routine.
Instead of just brightening one square, the modified routine will
also brighten the horizontal and vertical reflections of that square.
But how will it brighten each of the four individual squares?
By calling the brighten() method from the original
class. It can do this by calling super.brighten().
There is still the problem of computing the row and column numbers
of the horizontal and vertical reflections. To do this, you need
to know the number of rows and the number of columns. The
RandomBrighten class has instance variables named
ROWS and COLUMNS to represent these quantities.
Using these variables, it's possible to come up with formulas
for the reflections, as shown in the definition of the brighten()
method below.
Here's the complete definition of the new class:
public class SymmetricBrighten extends RandomBrighten {
void brighten(int row, int col) {
// Brighten the specified square and its horizontal
// and vertical reflections. This overrides the brighten
// method from the RandomBrighten class, which just
// brightens one square.
super.brighten(row, col);
super.brighten(ROWS - 1 - row, col);
super.brighten(row, COLUMNS - 1 - col);
super.brighten(ROWS - 1 - row, COLUMNS - 1 - col);
}
} // end class SymmetricBrighten
This is the entire source code for the applet at the bottom
of this page.
Constructors in Subclasses
Constructors are not inherited. That is, if you extend an existing class
to make a subclass, the constructors in the superclass do not become
part of the subclass. If you want constructors in the subclass, you have
to define new ones from scratch. If you don't define any constructors
in the subclass, then the computer will make up a default constructor,
with no parameters, for you.
This could be a problem, if there is a constructor in the superclass
that does a lot of necessary work. It looks like you might have to repeat
all that work in the subclass! This could be a real problem
if you don't have the source code to the superclass, and don't know how
it works, or if the constructor in the superclass initializes private
member variables that you don't even have access to in the subclass!
Obviously, there has to be some fix for this, and there is. It involves
the special variable, super, which was introduced in the
previous subsection. As the very first statement in a constructor, you
can use super to call a constructor from the superclass. The notation
for this is a bit ugly and misleading, and it can only be used in this one
particular circumstance: It looks like you are calling super as
a subroutine (even though super is not a subroutine and you can't
call constructors the same way you call other subroutines anyway). As an example,
assume that the PairOfDice class has a constructor
that takes two integers as parameters. Consider a subclass:
public class GraphicalDice extends PairOfDice {
public GraphicalDice() { // Constructor for this class.
super(3,4); // Call the constructor from the
// PairOfDice class, with parameters 3, 4.
initializeGraphics(); // Do some initialization specific
// to the GraphicalDice class.
}
.
. // More constructors, methods, variables...
.
}
This might seem rather technical, but unfortunately it is sometimes
necessary. By the way, you can use the special variable this
in exactly the same way to call another constructor in the same class.
This can be useful since it can save you from repeating the same code
in several constructors.
More about Access Modifiers
A class can be declared to be public. A public class can be
accessed from anywhere. Certain classes have to be public. A class that
defines a stand-alone application must be public, so that the system will
be able to get at its main() routine. A class that defines
an applet must be public so that it can be used by a Web browser. If
a class is not declared to be public, then it can only be used
by other classes in the same "package" as the class.
Packages are discussed in Section 4.5.
Classes that are not explicitly declared to be in any package
are put into something called the default package. All the examples
in this textbook are in the default package, so they are all
accessible to one another whether or not they are declared public.
So, except for applications and applets, which must be public,
it makes no practical difference whether our classes are declared
to be public or not.
However, once you start writing packages, it does make a difference.
A package should contain a set of related classes. Some of those classes
are meant to be public, for access from outside the package. Others
can be part of the internal workings of the package, and they should
not be made public. A package is a kind of black box. The public
classes in the package are the interface. (More exactly, the public
variables and subroutines in the public classes are the interface).
The non-public classes are part of the non-public implementation.
Of course, all the classes in the package have unrestricted access
to one another.
Following this model, I will tend to declare a class public
if it seems like it might have some general applicability.
If it is written just to play some sort of auxiliary role
in a larger project, I am more likely not to make it
public.
A member variable or subroutine in a class can also be declared to be
public, which means that it is accessible from anywhere.
It can be declared to be private, which means that it
accessible only from inside the class where it is defined.
Making a variable private gives you complete control over
that variable. The only code that will ever manipulate it
is the code you write in your class. This is an important
kind of protection.
If no access modifier is specified for a variable or subroutine,
then it is accessible from any class in the same package as the class.
As with classes, in this textbook there is no practical difference between
declaring a member public and using no access modifier at all.
However, there might be stylistic reasons for
preferring one over the other. And a real difference does arise once
you start writing your own packages.
There is a third access modifier that can be applied to a member
variable or subroutine. If it is declared to be protected,
then it can be used in the class where it is defined and in any
subclass of that class. This is obviously less restrictive than
private and more restrictive than public.
Classes that are written specifically to be used as a basis
for making subclasses often have protected members.
The protected members are there to provide a
foundation for the subclasses to build on. But they are still
invisible to the public at large.
Mixing Static and Non-static
Classes, as I've said, have two very distinct purposes. A class can be used
to group together a set of static member variables and static member
subroutines. Or it can be used as a factory for making objects.
The non-static variables and subroutine definintions in the class
specify the instance variables and methods of the objects. In most cases,
a class performs one or the other of these roles, not both.
Sometimes, however, static and non-static members are mixed in a single
class. In this case, the class plays a dual role. Sometimes, these
roles are completely separate. It is also possible for the static and
non-static parts of a class to interact. This happens when instance
methods use static member variables or call static member subroutines.
An instance method belongs to an object, not to the class itself, and there
can be many objects with their own versions of the instance method.
But there is only one copy of a static member variable. So, effectively,
we have many objects sharing that one variable.
As an example, let's rewrite the Student class that
was used in the Section 2. I've added
an ID for each student and a static member
called nextUniqueID. Although there is an
ID variable in each student object, there is
only one nextUniqueID variable.
public class Student {
private String name; // Student's name.
private int ID; // Unique ID number for this student.
public double test1, test2, test3; // Grades on three tests.
private static int nextUniqueID = 0;
// keep track of next available unique ID number
Student(String theName) {
// Constructor for Student objects;
// provides a name for the Student,
// and assigns the student a unique
// ID number.
name = theName;
nextUniqueID++;
ID = nextUniqueID;
}
public String getName() {
// Accessor method for reading value of private
// instance variable, name.
return name;
}
public int getID() {
// Accessor method for reading value of ID.
return ID;
}
public double getAverage() {
// Compute average test grade.
return (test1 + test2 + test3) / 3;
}
} // end of class Student
The initialization "nextUniqueID = 0" is done only once,
when the class is first loaded. Whenever a Student object is constructed
and the constructor says "nextUniqueID++;", it's always the
same static member variable that is being incremented. When the very first Student
object is created, nextUniqueID becomes 1. When the second object is
created, nextUniqueID becomes 2. After the third object, it becomes 3.
And so on. The constructor stores the new value of nextUniqueID in
the ID variable of the object that is being created. Of course,
ID is an instance variable, so every object has its own individual
ID variable. The class is constructed so that each student will
automatically get a different value for its ID variable. Furthermore,
the ID variable is private, so there is no way for this
variable to be tampered with after the object has been created.
You are guaranteed, just by the way the class is designed, that every
student object will have its own permanent, unique identification number.
Which is kind of cool if you think about it.
End of Chapter 5
