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