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

When the view is set up, the constructor of Simulator has the following calls to its setColor
method:

view.setColor(Rabbit.class, Color.ORANGE);
view.setColor(Fox.class, Color.BLUE);

We won't go into any further detail about Class , but this description should be sufficient to en-
able you to understand the code shown in the previous section.

10.9 Abstract class or interface?

In some situations, a choice has to be made between whether to use an abstract class or an
interface. Sometimes the choice is easy: when the class is intended to contain implementations
for some methods, we need to use an abstract class. In other cases, either abstract classes or
interfaces can do the job.

If we have a choice, interfaces are usually preferable. If we provide a type as an abstract class,
then subclasses cannot extend any other classes. Because interfaces allow multiple inheritance,
the use of an interface does not create such a restriction. Therefore, using interfaces leads to a
more flexible and more extendible structure.

10.10 Event-driven simulations

The style of simulation we have used in this chapter has the characteristic of time passing in
discrete, equal-length steps. At each time step, each actor in the simulation was asked to act—
i.e., take the actions appropriate to its current state. This style of simulation is sometimes called
time-based , or synchronous , simulation. In this particular simulation, most of the actors will
have had something to do at each time step: move, breed, and eat. In many simulation sce-
narios, however, actors spend large numbers of time steps doing nothing—typically, waiting for
something to happen that requires some action on their part. Consider the case of a newly born
rabbit in our simulation, for instance. It is repeatedly asked whether it is going to breed, even
though it takes several time steps before this is possible. Isn't there a way to avoid asking this
unnecessary question until it is actually ready?

There is also the question of the most appropriate size of the time step. We deliberately
left vague the issue of how much real time a time step represents, and the various actions
actually require significantly different amounts of time (eating and movement should
occur much more frequently than giving birth, for instance). Is there a way to decide on
a time-step size that is not so small that most of the time nothing will be happening or
too long that different types of actions are not distinguished clearly enough between time
steps?

An alternative approach is to use an event-based , or asynchronous , simulation style. In
this style, the simulation is driven by maintaining a schedule of future events. The most
obvious difference between the two styles is that, in an event-based simulation, time
passes in uneven amounts. For instance, one event might occur at time t and the next two
events occur at times t+2 and time t+8 , while the following three events might all occur
at time t+9 .