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

490 Chapter 12 Aggregation, Composition, and Inheritance
Even though it may be difficult to see palpable benefits from the use of final, go ahead and use it when appropriate. And even if you don’t use it for your own programs, you’ll need to understand it because you’ll see it quite often in the Java API library classes. For example, the Math class is defined with the final access modifier, so it’s illegal to extend the Math class and override any of its methods.
12.9 Using Inheritance with Aggregation and Composition
We have described several ways classes can be related—with aggregation, composition, and inheritance.
Now let’s consider using all three relationships together.
Aggregation, Composition, and Inheritance Compared
Aggregation and composition both implement a has-a relationship. We call aggregation and composition relationships has-a relationships because one class, the container class, has a component class inside of it. For example, in Section 12.2’s Dealership program, a dealership has a sales manager, with non-exclusive ownership rights, and that’s why the Dealership program implements the Dealership-SalesManager relationship with aggregation. Also, a dealership has an inventory of cars, with exclusive ownership rights, and that’s why the Dealership program implements the Dealership-Car relationship with composition.
Inheritance implements an is-a relationship. We call an inheritance relationship an is-a relationship be-
cause one class, a subclass, is a more detailed version of another class. For example, in the Person/Employee/
FullTime program, a full-time employee is an employee, and that’s why the program implements the Full-
Time-Employee relationship with inheritance. Also, an employee is a person, and that’s why the program Apago PDF Enhancer
implements the Employee-Person relationship with inheritance as well.
It’s important to keep in mind that these are not alternative ways to represent the same relationship.
They are ways to represent different relationships. The aggregation and composition relationships are when one class is a whole made up of non-trivial constituent parts defined in other classes. The inheritance rela- tionship is when one class is a more detailed version of another class. More formally, inheritance is when one class, a subclass, inherits variables and methods from another class, a superclass, and then supplements those with additional variables and methods. Since composition and inheritance deal with different aspects of a problem, many programming solutions include a mixture of both paradigms.
Aggregation, Composition, and Inheritance Combined
In the real world, it’s fairly common to have aggregation, composition, and inheritance relationships to- gether in the same program. Let’s look at an example that uses all three class relationships. Section 12.2’s Dealership program uses aggregation and composition, as illustrated by this UML class diagram:
Dealership
111
*1*
Car Manager SalesPerson