Page 533 - Introduction to Programming with Java: A Problem Solving Approach

12.11 Problem Solving with Association Classes (Optional) 499
program. Then suppose some eager salesperson finally makes a sale to that first customer. The next question is, where should we put the information about that sale? In the Dealership class? In the SalesPerson class (as we seem to be doing in Figure 12.6)? In the Car class? In the Customer class? Technically, we could put that information in any one of these classes, and then put references to that class in whatever classes need access to that information. We could also scatter the information around among the participat- ing classes in some way. No matter which of these alternatives we picked, however, from some points of view, what we did would seem inappropriate.
A more elegant solution is to encapsulate all of the sale information into one association class, and give that class a name that describes the association. That’s what we portray in Figure 12.22, which shows an ab- breviated class diagram of another version of our previous Dealership program. First, look at the Customer class. Since a customer is a person, just like the sales manager and sales people, we can use inheritance to reduce code and avoid redundancy in the Customer class by making the Customer class extend the Person class. Second, look at the Sale class. The Sale class appears as just another component in the Dealership class diagram. The one-to-many multiplicity suggests that its objects are elements of an ArrayList, perhaps named sales, which is instantiated in an enhanced version of the Dealership constructor. As far as the dealership is concerned, a Sale would be just another type of aggregation or composition component, like a SalesPerson2 or a Car.
Person
Apago PDF Enhancer
Manager2 Customer
SalesPerson2
1*
Sale is an association class.
Car Sale
**
1111
Dealership3
Figure 12.22 Class diagram for another car dealership program with customers and a salesperson-car-customer association
However, a sale is not a physical entity, like an organism or car is. It’s a process—or event—that associ- ates a group of entities. So the Sale class needs to be an association class. What types of objects partici- pate in a Sale association? There’s a Car, there’s a SalesPerson2, and there’s a Customer. Notice how the UML class diagram in Figure 12.22 uses simple solid association lines to interconnect all normal classes that participate in an association. The UML standard suggests ways to decorate these association lines with additional symbols and nomenclature, but just the lines shown convey the message—the idea of an association among objects of the Car, SalesPerson2, and Customer classes. The dashed line that connects the Sale class to the solid association lines graphically identifies the Sale class as an as- sociation class describing the related association. The code fragment in Figure 12.23 illustrates the Sale constructor.