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 PhysicalID s .

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 Rental s:

 class RentalContract         Rentals [] the_rentals 

This change provokes many questions. Should RentalContract contain Customer or should we just use the information in one Rental ? We already have the Rental class working. Multiple Rental s in RentalContract have the same Customer . All the information is there, but it is duplicated .

Should Rental s be changed to refer to a RentalContract , rather than to a Customer ? If we do that, what do we do about all the Rental s that we already recorded? What could the migration path be for those Rental s? Do we make up fake RentalContract s for them and point them to those fake RentalContract s?

We are unclear as to what is the true meaning of RentalContract . Is it a temporary item, just for the purposes of printout, or is it a persistent item? With all these questions, it's obvious we don't completely understand the problem. We check back with Sam.

"What's your definition of a rental contract?" we asked.

Sam replied, "A rental contract shows one or more rentals by a single customer at a single time."

"Is a contract just a piece of paper, or is it something we need to keep track of?" I asked. "Think carefully , because the answer will affect your pocketbook."

Sam pondered the question for a moment. "I'm not sure what you mean."

"About your pocketbook or the contract?" I asked.

"The contract," he stated.

"Once a rental has begun, does the system have to remember the contract on which it was printed?" I asked.

Sam replied, "I think I know what you are getting at. The contract is just a piece of paper. We file it away in date order, just in case a customer makes a stink. We probably look up a contract once a month. Since they're all filed by date and we can determine from the card when the customer rented a particular disc, it's pretty easy to find. So I don't want to spend a bundle, if that's what you're asking."

"Good," I replied. "I'd rather you save your money for more important things."

Our current concept of Rental remains the same. Now its creation appears in the context of RentalContract . However we already use the term , RentalContract , in the RentalContractDTO in Chapter 7. Should we alter RentalContractDTO 's details to apply it to a contract with multiple rentals, or should we create a new term? Once you have general agreement on the meaning of a term, altering its meaning can cause confusion. ^[*]

^[*] An equivalent concept in methods is that is always easy to add new methods to a class, but it is difficult to alter the contracted behavior of existing methods . Other classes that depend on the current behavior will need to be altered .

DON'T CHANGE WHAT IT IS

Create new terms rather than trying to apply new meanings to current terms .

A multiple rental contract has a different meaning than the current rental contract. So we create a new Data Transfer Object (DTO).

 class SingleRentalDTO         Timestamp rental_start_time         Timestamp rental_due_time         CommonString cd_release_title         PhysicalId cd_disc_physical_id     class MultipleRentalContractDTO         SingleRentalDTO [] single_rentals         Name customer_name;         PhoneNumber customer_day_phone_number; 

The new class that contains Rental s is MultipleRental . It has the responsibility of computing the total price for all Rental s, as well as creating the MultipleRentalDTO .

 class MultipleRental         private Rental []         add_rental(Rental)         Rental  get_rentals( )         Dollar compute_total_price( )         MultipleRentalDTO calculate_multiple_rental_contract( ) 

We need to alter the user interface to appear as shown in Figure 12-1. The RentalOperation class needs operations involving multiple rentals. We also need to create and print the report using the MultipleRentalContractDTO .

 RentalOperations         MultipleRental start_new_multiple_rental(CustomerID customer_id)         add_cd_disc_to_multiple_rental(MultipleRental multiple_rental,             PhysicalID physical_id)         MultipleRentalContractDTO end_multiple_rental(MultipleRental multiple_rental)