Java Reference
In-Depth Information
implementation of the simulation as a whole. As with the project in Chapter 8, using a common
superclass should avoid code duplication in the subclasses and simplify the code in the client
class (here,
Simulator
). It is important to note that we are undertaking a process of refactoring
and that these changes should not change the essential characteristics of the simulation as seen
from a user's viewpoint.
10.3.1 The
Animal
superclass
For the first set of changes, we will move the identical elements of
Fox
and
Rabbit
to an
Animal
superclass. The project
foxes-and-rabbits-v1
provides a copy of the base version of the
simulation for you to follow through the changes we make.
■
Both
Fox
and
Rabbit
define
age
,
alive
,
field
, and
location
attributes. However, at
this point we will only move
alive
,
location
, and
field
to the
Animal
superclass and
come back to discuss the
age
field later. As is our normal practice with instance fields, we
will keep all of these private in the superclass. The initial values are set in the constructor of
Animal
, with
alive
set to
true
, and
field
and
location
passed via
super
calls from
the constructors of
Fox
and
Rabbit
.
■
These fields will need accessors and mutators, so we can move the existing
getLocation
,
setLocation
,
isAlive
, and
setDead
from
Fox
and
Rabbit
. We will also need to add a
getField
method in
Animal
so that direct access to
field
from the subclass methods
run
,
hunt
,
giveBirth
, and
findFood
can be replaced.
■
In moving these methods, we have to think about the most appropriate visibility for them.
For instance,
setLocation
is private in both
Fox
and
Rabbit
, but cannot be kept private in
Animal
because
Fox
and
Rabbit
would not be able to call it. So we should raise it to
pro-
tected
visibility, to indicate that it is for subclasses to call.
■
In a similar vein, notice that
setDead
was public in
Rabbit
but private in
Fox
. Should it
therefore be public in
Animal
? It was public in
Rabbit
because a fox needs to be able to call a
rabbit's
setDead
method when it eats its prey. Now that they are sibling classes of a shared su-
perclass, a more appropriate visibility is
protected
, again indicating that this is a method that
is not a part of an animal's general interface—at least at this stage of the project's development.
Making these changes is a first step toward eliminating code duplication through the use of
inheritance, in much the same way as we did this in Chapter 8.
Exercise 10.30
What sort of regression-testing strategy could you establish before undertaking
the process of refactoring on the simulation? Is this something you could conveniently automate?
Exercise 10.31
The
Randomizer
class provides us with a way to control whether the
“random” elements of the simulation are repeatable or not. If its
useShared
field is set to
true
, then a single
Random
object is shared between all of the simulation objects. In addition,
its
reset
method resets the starting point for the shared
Random
object. Use these features
as you work on the following exercise, to check that you do not change anything fundamental
about the overall simulation as you introduce an
Animal
class.
Search WWH ::
Custom Search