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

14.3 Class design

In this section, we shall start to make the move from a high-level abstract design on paper to a
concrete outline design within a BlueJ project.

14.3.1 Designing class interfaces

In Chapter 13, we suggested that the next step was to create a fresh set of CRC cards from the
first, turning the responsibilities of each class into a set of method signatures. Without wishing to
de-emphasize the importance of that step, we shall leave it for you to do and move directly to a
BlueJ project outline containing stub classes and methods. This should provide a good feel for the
complexity of the project and whether we have missed anything crucial in the steps taken so far.

It is worth pointing out that, at every stage of the project life cycle, we should expect to find
errors or loose ends in what we have done in earlier stages. This does not necessarily imply that
there are weaknesses in our techniques or abilities. It is more a reflection of the fact that project
development is often a discovery process. It is only by exploring and trying things out that we
gain a full understanding of what it is we are trying to achieve. So discovering omissions actu-
ally says something positive about the process we are using!

14.3.2 Collaborators

Having identified collaborations between classes, one issue that will often need to be addressed
is how a particular object obtains references to its collaborators. There are usually three distinct
ways in which this happens, and these often represent three different patterns of object interaction:

■ A collaborator is received as an argument to a constructor. Such a collaborator will usually
be stored in one of the new object's fields so that it is available through the new object's
life. The collaborator may be shared in this way with several different objects. Example:
A PassengerSource object receives the TaxiCompany object through its constructor.

■ A collaborator is received as an argument to a method. Interaction with such a collaborator is
usually transitory—just for the period of execution of the method—although the receiving object
may choose to store the reference in one of its fields, for longer-term interaction. Example:
TaxiCompany receives a Passenger collaborator through its method to handle a pickup request.
■ The object constructs the collaborator for itself. The collaborator will be for the exclusive
use of the constructing object, unless it is passed to another object in one of the previous
two ways. If constructed in a method, the collaboration will usually be short term, for the
duration of the block in which it is constructed. However, if the collaborator is stored in a
field, then the collaboration is likely to last the full lifetime of the creating object. Example:
TaxiCompany creates a collection to store its vehicles.

Exercise 14.11 As the next section discusses the taxi-company-outline project, pay particu-
lar attention to where objects are created and how collaborating objects get to know about each
other. Try to identify at least one further example of each of the patterns we have described.