Java Reference
In-Depth Information
Exercise 14.26 Add assertion and exception-throwing consistency checks within each
class, to guard against inappropriate use. For instance, ensure that a Passenger is never
created with pickup and destination locations that are the same; ensure that a taxi is never
requested to go to a pickup when it already has a target location; etc.
Exercise 14.27 Report on the statistical information that is being gathered by taxis and the
passenger source; also on taxi idle time and missed pickups. Experiment with different num-
bers of taxis to see how the balance between these two sets of data varies.
Exercise 14.28 Adapt the vehicle classes so that records are kept of the amount of time
spent traveling to pickup locations and passenger destinations. Can you see a possible
conflict here for shuttles?
14.4.5
Further ideas for development
The version of the application provided in the taxi-company-later-stage project represents a
significant point in the development toward full implementation. However, there is still a lot
that can be added. For instance, we have hardly developed the Shuttle class at all, so there
are plenty of challenges to be found in completing its implementation. The major difference
between shuttles and taxis is that a shuttle has to be concerned with multiple passengers,
whereas a taxi has to be concerned with only one. The fact that a shuttle is already carrying a
passenger should not prevent it from being sent to pick up another. Similarly, if it is already on
its way to a pickup, it could still accept a further pickup request. These issues raise questions
about how a shuttle organizes its priorities. Could a passenger end up being driven back and
forth while the shuttle responds to competing requests, the passenger never getting delivered?
What does it mean for a shuttle not to be free? Does it mean that it is full of passengers or that
it has enough pickup requests to fill it? Suppose at least one of those pickups will reach their
destination before the final pickup is reached: Does that mean it could accept more pickup
requests than its capacity?!
Another area for further development is vehicle scheduling. The taxi company does not op-
erate particularly intelligently at present. How should it decide which vehicle to send when
there may be more than one available? No attempt is made to assign vehicles on the basis of
their distance from a pickup location. The company could use the distance method of the
Location class to work out which is the nearest free vehicle to a pickup. Would this make a
significant difference to the average waiting time of passengers? How might data be gathered
on how long passengers wait to be picked up? What about having idle taxis move to a central
location, ready for their next pickup, in order to reduce potential waiting times? Does the size
of the city have an impact on the effectiveness of this approach? For instance, in a large city,
is it better to have idle taxis space themselves out from one another rather than have all gather
at the center?
Could the simulation be used to model competing taxi companies operating in the same area
of the city? Multiple TaxiCompany objects could be created and the passenger source allocate
passengers to them competitively on the basis of how quickly they could be picked up. Is this
too fundamental a change to graft onto the existing application?
Search WWH ::




Custom Search