Page 515 - Introduction to Programming with Java: A Problem Solving Approach
P. 515

                12.3 Inheritance Overview 481
     -name : String
Person
  +Person() +Person(name : String) +getName() : String
    Employee
Customer
  -id : int
+Employee()
+Employee(name : String, id : int) +display() : void
-address : String
  +setAddress(address : String) : void +getAddress() : String
   PartTime
 -hourlyWage : double
     FullTime
 -salary : double
   +FullTime()
+FullTime(name : String, id : int, salary : double)
+display() : void Apago PDF Enhancer
Figure 12.9 UML class diagram for a Person class inheritance hierarchy
classes inherit id from the Employee class. Inheritance travels all the way down the inheritance hierarchy tree, so in addition to inheriting id from the Employee class, the FullTime and PartTime classes also inherit name from the Person class.
Within an inheritance hierarchy, classes are linked in pairs. Can you identify the linked pairs in Figure 12.9? The four pairs of linked classes are Person-Customer, Person-Employee, Employee- FullTime, and Employee-PartTime. For each pair of linked classes, the more general class is consid- ered to be the superclass and the more specific one is considered to be the subclass.
Inheriting a superclass’s variables and methods enables a subclass to be a clone of its superclass. But making a subclass that’s just a clone would be silly, because you could just use the superclass instead. You always want a subclass to be a more specific version of its superclass. That’s achieved by establishing addi- tional variables and/or methods inside the subclass’s definition. For example, in Figure 12.9, the Customer class defines an address instance variable. That means Customer objects have a name (inherited from the Person class) plus an address. Customer addresses are important in that they enable department stores to mail monthly “Everything-Must-Go Liquidation Sale!” advertisements to their customers.
UML class diagrams usually show superclasses above subclasses. However, that’s not always the case. With large projects, you’ll have lots of classes and several different types of relationships among the classes. With all that going on, it’s sometimes impossible to draw a “clean” class hierarchy picture and preserve the traditional superclass-above-subclass layout. Thus, subclasses sometimes appear at the left, at the right, or even above their superclasses. So how can you tell which is the subclass and which is the superclass? UML












































































   513   514   515   516   517