OOPDA Lab 06-A – Make a superclass➔ USE foxes-and-rabbits-v1 as the starting point for this assignment.
1. Start a Lab6ALOG file in WORD [or Google docs] for screen shots and notes as you proceed.
2. Download the project, and run main() in Tester.java. Note that this short driver creates a
Simulator object, and then invokes the method
void simulate(int numSteps) with a parameter of 500.
3. Observe the simulation with 500 steps and record the number of foxes and the number of rabbits after a
test run. Take a screen shot at end of the run, and paste into your LOG file.
4. Repeat a run. Did you get the same values the second time? Note these values for later, and make another
screen shot.
Read the discussion below very carefully, take your time, and do exactly what it says!!
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 f el d 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 protected visibility,
to indicate that it is for suclasses 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 superclass,
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:
•
Create the Animal superclass in your version of the project. Make the
changes discussed above.
•
Ensure that the simulation works in a similar manner as before. Make a
screen shot at end of run. Did the test run yield the same results as the
initial version?
Lab Deliverable: zip of Eclipse project folder, plus LOG file with screen shots of
end of initial run, and end of final run after changes.
Lab 06A_was05-2 – Make the Animal Superclass Ex12.32ff – FA22
8/11/2022 2:09 PM