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

Code 14.1
continued
An outline of the
Vehicle class

public void clearTargetLocation()
{

targetLocation = null ;

}

}

The process of creating the outline project raised a number of issues. Here are some of them:

■ You should expect to find some differences between the design and the implementation, ow-
ing to the different natures of design and implementation languages. For instance, discussion
of the scenarios suggested that PassengerSource should have the responsibility Generate
pickup and destination locations for a passenger , and Passenger should have the responsi-
bility Receive pickup and destination locations . Rather than mapping these responsibilities to
individual method calls, the more natural implementation in Java is to write something like
new Passenger(new Location(...), new Location(...))

■ We have ensured that our outline project is complete enough to compile successfully. That
is not always necessary at this stage, but it does mean that undertaking incremental develop-
ment at the next stage will be a little easier. However, it does have the corresponding disad-
vantage of making missing pieces of code potentially harder to spot, because the compiler
will not point out the loose ends.

■ The shared and distinct elements of the Vehicle , Taxi , and Shuttle classes only really
begin to take shape as we move towards their implementation. For instance, the different ways
in which taxis and shuttles respond to a pickup request is reflected in the fact that Vehicle
defines setPickupLocation as an abstract method, which will have separate concrete im-
plementations in the subclasses. On the other hand, even though taxis and shuttles have dif-
ferent ways of deciding where they are heading, they can share the concept of having a single
target location. This has been implemented as a targetLocation field in the superclass.
■ At two points in the scenario, a vehicle is expected to notify the company of its arrival at
either a pickup point or a destination. There are at least two possible ways to organize this in
the implementation. The direct way is for a vehicle to store a reference to its company. This
would mean that there would be an explicit association between the two classes on the class
diagram.
An alternative is to use the Observer pattern introduced in Chapter 13, with Vehicle
extending the Observable class and TaxiCompany implementing the Observer interface.
Direct coupling between Vehicle and TaxiCompany is reduced, but implicit coupling is
still involved, and the notification process is a little more complex to program.

■ Up to this point, there has been no discussion about how many passengers a shuttle can carry.
Presumably there could be different-sized shuttles. This aspect of the application has been
deferred until a later resolution.

There is no absolute rule about exactly how far to go with the outline implementation in any
particular application. The purpose of the outline implementation is not to create a fully work-
ing project, but to record the design of the outline structure of the application (which has been