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

474 Chapter 12 Aggregation, Composition, and Inheritance Composition and Aggregation in a Java Program
Let’s look at an example that uses both class relationships—composition (where exclusive ownership is re- quired) and standard aggregation (where exclusive ownership is not required). Suppose you’re trying to model a car dealership with a computer program. Since the car dealership is made from several distinct non-trivial parts, it’s a good candidate for being implemented as an aggregation. The “whole” (the top of the aggregation hierarchy) is the dealership. Typically, a business has two kinds of “parts”– people and property. For simplicity, suppose the only types of people at the car dealership are management and sales people, and suppose the only type of property is cars. The control the dealership has over the people is limited. They may also have other jobs, and they may have family obligations. The dealership does not own its employees exclusively. Therefore, the relationship between the dealership and its employees is just aggregation. But the dealership does own its cars exclusively. So that relationship is composition. Note that the dealership can transfer ownership of its cars to its customers. That’s OK because composition permits ownership to be transferred. Using a bottom-up design methodology, you should define three classes—Car, Manager, and SalesPerson—for the three types of component objects. Then, you should define a Dealership class for the container object.
Before you see the Dealership program’s code, let’s focus on the big-picture concepts using a UML class diagram. Figure 12.2’s UML class diagram shows the Dealership program’s four classes and the relationships among them. Since we’re now focusing on just the relationships among classes, in each representation of a class, we include just the class name and omit variables and methods. That’s OK—UML is very flexible, and such omissions are allowed by the UML standards. UML indicates class relationships with connecting lines that run from one class to another. Formally, each connecting line is called an association line.
Apago PDF Enhancer
containing class
composition relationship
aggregation relationships
Car Manager SalesPerson
Dealership
111 *1*
Figure 12.2 Class diagram for Dealership program
In Figure 12.2, note the diamonds on the association lines. Solid diamonds (like the one on the Dealership-Car line) indicate composition relationships, and hollow diamonds (like the ones on the Dealership-Manager and Dealership-SalesPerson lines) indicate aggregation relationships. The diamonds always go next to the containing class, so Figure 12.2’s class diagram indicates that Dealership is the containing class.
Notice the numbers and asterisks written beside the association lines. These are multiplicity values that UML uses to specify the number of objects that participate in associations. The two 1’s on the line between Dealership and Manager indicate a one-to-one association. That means there’s one manager for each car dealership. If there were a 2 multiplicity value for the manager class, that would indicate two managers for each car dealership. The combination of 1 and * on the other two association lines indicates one-to-many associations, where “many” implies an indefinite number. That means you can have lots of cars (or none) and lots of sales people (or none) for one car dealership.
It’s now time to move from the conceptual phase, with emphasis on the dealership’s UML class dia- gram, to the implementation phase, with emphasis on the Dealership program code. Note the Dealership class in Figure 12.3, and in particular, note the manager, people, and cars instance variables declared