Further abstraction techniques - Objects First with Java: A Practical Introduction Using BlueJ - page 351

have on the existing animal types. For instance, your animal might compete with foxes as a
predator on the rabbit population, or your animal might prey on foxes but not on rabbits. You
will probably find that you need to experiment quite a lot with the configuration settings you
use for it. You will need to modify the populate method to have some of your animals cre-
ated at the start of a simulation.

You should also define a new color for your new animal class. You can find a list of pre-
defined color names on the API page documenting the Color class in the java.awt
package.

Exercise 10.51 Challenge exercise The text of the giveBirth methods in Fox and
Rabbit is very similar. The only difference is that one creates new Fox objects and the other
creates new Rabbit objects. Is it possible to use the technique illustrated with canBreed to
move the common code into a shared giveBirth method in Animal ? If you think it is, try it
out. Hint : The rules on polymorphic substitution apply to values returned from methods as well
as in assignment and parameter passing.

10.5 Multiple inheritance

10.5.1 An Actor class
In this section, we discuss some possible future extensions and some programming constructs
to support these extensions.

The first obvious extension for our simulation is the addition of new animals. If you have
attempted Exercise 10.50 then you will have touched on this already. We should, however,
generalize this a bit: maybe not all participants in the simulation will be animals. Our current
structure assumes that all acting participants in the simulation are animals and that they inherit
from the Animal superclass. One enhancement that we might like to make is the introduction
of human predators to the simulation, as either hunters or trappers. They do not neatly fit the
existing assumption of purely animal-based actors. We might also extend the simulation to
include plants eaten by the rabbits, or even some aspects of the weather. The plants as food
would influence the population of rabbits (in effect, rabbits become predators of the plants), and
the growth of the plants might be influenced by the weather. All these new components would
act in the simulation, but they are clearly not animals, so it would be inappropriate to have them
as subclasses of Animal .

As we consider the potential for introducing further actors into the simulation, it is worth
revealing why we chose to store details of the animals in both a Field object and an Animal
list. Visiting each animal in the list is what constitutes a single simulation step. Placing all par-
ticipants in a single list keeps the basic simulation step simple. However, this clearly duplicates
information, which risks creating inconsistency. One reason for this design decision is that it
allows us to consider participants in the simulation that are not actually within the field—a rep-
resentation for the weather might be one example of this.