9.2. Who s in Charge?

 <  Day Day Up  >  

9.2. Who's in Charge?

Are CDDisc s rented to customers or do customers rent CDDiscs? That might seem like a redundant question, but the decision of who is in charge underlies many design issues.

9.2.1. One Class in Charge

In the first version of the system, CDDisc had the start_rental and end_rental operations. When start_rental was invoked, it created a Rental . If we want to know what CDDisc s a particular customer is renting at the current time, we have to ask every CDDisc if it is rented to that Customer . CDDisc would need some additional methods :

 class CDDisc         {         start_rental(Customer a_customer);             // Begins a rental for particular customer         end_rental( );  // Ends the rental for that customer         Customer retrieve_renting_customer( );         Customer [] retrieve_all_customers_who_rented( );         }; 

Should Customer keep track of what CDDisc s are rented to it? If so, at the time of the rental, we would call a method in the Customer class to record the rental and a corresponding method at the end of the rental:

 class Customer         {         begin_rental(CDDisc a_cd_disc);         end_rental(CDDisc a_cd_disc);         Rentals [] retrieve_current_rentals( );         }; 

In Sam's current system, we have three classes: CDDisc , Rental , and Customer . A Rental object is currently a member of the CDDisc class. But Rental has a reference to the Customer class. So CDDisc is coupled to Rental and Rental is coupled to Customer . This organization worked OK when we had a one-to-one relationship between the classes. In essence, a CDDisc was tied to a customer through a level of indirection. This tie was temporal. When the customer returned the CDDisc , the association was broken. [*]

[*] Michael Green, a reviewer, suggested that one might discover a guideline in a retrospective: "Before discarding an association, check with the customer to see if it may be needed in the future. What kinds of questions might have been asked that would have helped foresee these changes and plan for them?"

9.2.2. Association Classes

We can approach the relationship between CDDisc and Customer in a different way. A rental represents the loan of a CDDisc to a Customer for a period of time. A rental that is completed could still exist. Its state would be different. Thus a rental can become a permanent association of a CDDisc to a Customer . For example:

 class Rental         Customer renter         CDDisc cd_disc         Timestamp start_time         Timestamp end_time         Dollar rental_fee         Days base_rental_period 

Association classes contain attributes that refer to two (or more) objects, as well as any data relative to the relationship. The objects that are linked typically represent different classes. Using an association class decouples the two linked classes. For example, in Sam's system, CDDisc no longer is coupled to Customer . Any methods in CDDisc referring to Customer are eliminated. (For more details on association classes , see Object-Oriented Modeling and Design by James R Rumbaugh et al. [Prentice Hall, 1990]).

Rental s are treated on an equal basis with CDDisc s and Customer s. A RentalCollection holds the Rental s, and appropriate methods are created to retrieve the Rental s, based on Sam's new requests . For example:

 class RentalCollection         {         RentalContractDTO start_rental(CDDisc a_cddisc, Customer a_customer);         end_rental_of_cddisc(CDDisc a_cddisc);         Rental [] retrieve_current_rentals_for_customer(Customer a_customer);         Rental [] retreive_all_rentals_for_customer(Customer a_customer);         Customer [] retrieve_customers_who_rented_a_cd_disc(CDDisc a_cd_disc);         Rental retrieve_current_rental_for_cd_disc(CDDisc a_cd_disc);         }; 

Figure 9-1 shows the class diagram for this approach.

The start_rental( ) method returns a RentalContractDTO . This is the same DTO that was produced in the previous system. Our reorganization of these classes does not affect the output reports . The reorganization affects only the CDDisc class and the RentalOperations class.

Figure 9-1. Rental association classes

DECOUPLE WITH ASSOCIATIONS

Association classes decouple the two classes being associated .


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net