A case study - Objects First with Java: A Practical Introduction Using BlueJ - page 495

The need to model movement required the Location class to be implemented more fully
than in the outline. On the face of it, this should be a relatively simple container for a two-
dimensional position within a rectangular grid. However, in practice, it also needs to provide
both a test for coincidence of two locations ( equals ), and a way for a vehicle to find out
where to move to next, based on its current location and its destination ( nextLocation ). At
this stage, no limits were put on the grid area (other than that coordinate values should be posi-
tive), but this raises the need in a later stage for something to record the boundaries of the area
in which the company operates.
One of the major issues that had to be addressed was how to manage the association between
a passenger and a vehicle, between the request for a pickup and the point of the vehicle's ar-
rival. Although we were required only to handle a single taxi and a single passenger, we tried
to bear in mind that ultimately there could be multiple pickup requests outstanding at any one
time. In Section 14.2.3, we had decided that a vehicle should receive its passenger when it noti-
fies the company that it has arrived at the pickup point. So, when a notification is received, the
company needs to be able to work out which passenger has been assigned to that vehicle. The
solution we chose was to have the company store a vehicle:passenger pairing in a map. When
the vehicle notifies the company that it has arrived, the company passes the corresponding pas-
senger to it. However, there are various reasons why this solution is not perfect, and we shall
explore this issue further in the exercises below.
One error situation we addressed was that there might be no passenger found when a vehicle
arrives at a pickup point. This would be the result of a programming error, so we defined the
unchecked MissingPassengerException class.
As only a single passenger was required for this stage, development of the PassengerSource
class was deferred to a later stage. Instead, passengers were created directly in the Demo and
Test classes.
Exercise 14.19 If you have not already done so, take a thorough look through the imple-
mentation in the taxi-company-stage-one project. Ensure that you understand how movement
of the taxi is effected through its act method.
Exercise 14.20 Do you feel that the TaxiCompany object should keep separate lists of
those vehicles that are free and those that are not, to improve the efficiency of its scheduling?
At what points would a vehicle move between the lists?
Exercise 14.21 The next planned stage of the implementation is to provide multiple taxis to
carry multiple passengers concurrently. Review the TaxiCompany class with this goal in mind.
Do you feel that it already supports this functionality? If not, what changes are required?
Exercise 14.22 Review the way in which vehicle:passenger associations are stored in the
assignments' map in TaxiCompany . Can you see any weaknesses in this approach? Does it
support more than one passenger being picked up from the same location? Could a vehicle
ever need to have multiple associations recorded for it?