Prefactoring

12.2. Change Happens

Sam dropped by. He began, "You know, one thing is bugging the staff and the customers a little bit."

"That's our job, to take out bugs," I replied. "What is it?"

"When the customer rents multiple CDDiscs, multiple rental contracts get printed. I'd like only one rental contract for all the discs rented at one shot," he said.

"Let's explore this more," I offered. "We separated out the printing of the contract from the rental itself. But now you want to change the concept of the rental contract. A rental contract, instead of being a printout of a single rental, is now a printout of multiple rentals. Is that right?"

"You've got it," Sam answered.

Sam and I developed an informal use case for this new procedure:

Rent_multiple_CDDiscs

1. The user enters a CustomerID .

2. The user enters one or more PhysicalIDs.

3. The system prints a rental contract

I prepared a prototype for the new screens, as shown in Figure 12-1. Sam agreed that they captured his idea of how the new procedure would work.

Figure 12-1. Multiple-rental interface

Now Tim and I are faced with reorganization. We have a new concept introduced into the requirements. If we were made aware of this in the beginning, we would have worked it into the design. The new concept is RentalContract. A RentalContract contains one or more Rentals:

    class RentalContract
        Rentals [] the_rentals

This change provokes many questions. ...