Designing applications - Objects First with Java: A Practical Introduction Using BlueJ - page 465

theater. So we assume that each show has a link to a Theater object. (Note this on the card:
Stores theater . This is also a collaborator.) The theater should probably know about the exact
number and arrangement of seats it has. (We can also note in the back of our heads, or on a
separate piece of paper, that each show must have its own instance of the Theater object,
because several shows can be scheduled for the same Theater and reserving a seat in one
does not reserve the same seat for another show. This is something to look out for when
Show objects are created. We have to keep this in mind so that later, when we play through
the scenario of Scheduling a new show , we remember to create a theater instance for each
show.) The way a show deals with reserving a seat is probably by passing this reservation
request on to the theater.
■ Now the theater has accepted a request to make a reservation. (Note this on the card: Accepts
reservation request .) How does it deal with it? The theater could have a collection of seats in
it. Or it could have a collection of rows (each row being a separate object), and rows, in turn,
hold seats. Which of these alternatives is better? Thinking ahead about other possible scenarios,
we might decide to go with the idea of storing rows. If, for example, a customer requests four
seats together in the same row, it might be easier to find four adjacent seats if we have them all
arranged by rows. We note on the Theater card: Stores rows . Row is now a collaborator.
■ We note on the Row class: Stores collection of seats . And then we note a new collaborator:
Seat .
■ Getting back to the Theater class, we have not yet worked out exactly how it should react
to the seat reservation request. Let us assume it does two things: find the requested row and
then make a reservation request with the seat number to the Row object.
■ Next, we note on the Row card: Accepts reservation request for seat . It must then find the right
Seat object (we can note that as a responsibility: Can find seats by number ) and can make a
reservation for that seat. It would do so by telling the Seat object that it is now reserved.
■ We can now add to the Seat card: Accepts reservations . The seat itself can remember whether
it has been reserved. We note on the Seat card: Stores reservation status (free/reserved) .
Exercise 13.4 Play this scenario through on your cards (with a group of people, if possible).
Add any other information you feel was left out in this description.
Should the seat also store information about who has reserved it? It could store the name of the
customer or the telephone number. Or maybe we should create a Customer object as soon as
someone makes a reservation, and store the Customer object with the seat once the seat has
been reserved? These are interesting questions, and we will try to work out the best solution by
playing through more scenarios.
This was just the first, simple scenario. We need to play through many more scenarios to get a
better understanding of how the system should work.
Playing through scenarios works best when a group of people sit around a table and move the
cards around on it. Cards that cooperate closely can be placed close together to give an impres-
sion of the degree of coupling in the system.