Inheritance, week 4 discussion help

One of the topics covered in this unit is “Inheritance“. The chapter shows the Person/Employee example, what are some other examples that could use Inheritance? Read section 13.3-13.4 and come up with your own example of inheritance. Explain your example in a 1 paragraph.

13_4
13.4 Implementation of a Person/Employee/ FullTime Hierarchy
To explain how to implement inheritance, we’ll implement the Person / Employee / FullTime hierarchy
shown in Figure 13.9. We’ll implement the Person and Employee classes in this section, and we’ll
implement the FullTime class in Section 13.6.
The Person class Figure 13.10 contains an implementation of the Person class. It will be a superclass,
but there’s no special code in the Person class indicating that it will be a superclass. The special code
comes later, when we define Person ’s subclasses. That’s where we indicate that Person is a superclass
for those subclasses.
The Person class doesn’t do much. It just provides a constructor that stores a name and an accessor that
retrieves it. However, it contains one item worth examining—the zero-parameter constructor. Normally,
when a driver instantiates a Person class, the driver will assign the person’s name by passing a name
argument to the one-parameter constructor. But suppose you want to test your program with a Person
object, and you don’t want to hassle with storing a name in the Person object. The zero-parameter
constructor allows you to do that. Do you know what name will be given to a Person object created by
the zero-parameter constructor? In this case, name is a string instance variable, and the default value
for a string instance variable is null . To avoid the ugly null default, note how name is initialized to the
empty string.
Quick quiz: Can you achieve the same functionality by omitting the zero-parameter constructor because
the compiler automatically provides a default zero-parameter constructor? Nope—remember that once
you write any constructor, the compiler no longer provides a default zero-parameter constructor.
The Employee Class
Figure 13.11 contains an implementation of the derived Employee class, which provides an id . Note the
extends clause in the Employee class’s heading. To enable inheritance, extends must
appear at the right of the subclass’s heading. Thus, extends Person appears at the right of the Employee
class’s heading. Note that the Employee class defines just one instance variable, id . Does that mean that
an Employee object has no name? No. Employee objects do have names because the Employee class
inherits the name instance variable from the Person superclass. Now you’ll learn how to access name
from within the Employee class.
The Employee class’s display method is in charge of printing an employee’s information— name and id .
Printing the id is easy because id is declared within the Employee class. Printing name requires a bit
more work. Since name is a private instance variable in the Person superclass, the Employee class
cannot access name directly (that’s the same interpretation of private that we’ve always had). But the
Employee class can access name by calling the Person class’s public getName accessor method. Here’s
the relevant code from the display method:
System.out.println(“name: ” + getName());
As you might recall, in an instance method, if you call a method that’s in the same class as the class
you’re currently in, the reference variable dot prefix is unnecessary. Likewise, in an instance method, if
you call a method that’s in the superclass of the class you’re currently in, the reference variable dot
prefix is unnecessary. Thus, there’s no reference variable dot prefix in this call to getName . While there
is complete agreement about the way that a subclass object can access a private instance variable from
its superclass (i.e., use a superclass public accessor method), there is disagreement about the
terminology used to describe such access. Some textbook authors say that a subclass object inherits
private instance variables from its superclass; others say that a subclass object does not inherit private
instance variables from its superclass. We fall into the inheritance camp because an instantiated
subclass contains private instance variables from the superclass. We know this because they are
accessible (via public methods) without having to instantiate a second object for the superclass. In an
explanation that would make a politician proud, Oracle first claims that private members are inherited,
and then later claims that private members are not inherited (see what we mean by looking at the
statement, at http://download.oracle.com/javase/tutorial/java/IandI/subclasses.html). No worries. The
terminology doesn’t matter, as long as you know how things work in terms of functionality.
13.3 Inheritance Overview
So far in this chapter, we’ve focused on aggregation and composition hierarchies, where one class is the whole and
other classes are parts of the whole. Now we turn to classification hierarchies, which are qualitatively different from
composition hierarchies. Whereas a composition hierarchy describes a nesting of things, a classification hierarchy
describes an elaboration of concepts. The concept at the top is the most general/generic, and the concepts at the
bottom are the most specific.
Classification Hierarchies and Inheritance of Attributes
Before looking at code, let’s think about a real-world classification example. Figure 13.8 describes a few of the many
possible characteristics of organisms living on the Earth today, with the most general characteristics at the top of the
diagram and the most specific characteristics at the bottom of the diagram. Although this chart includes only
characteristics of current living organisms, it’s helpful to recognize that there was a natural time sequence in the
development of these characteristics. The characteristics at the top developed first, and the characteristics at the
bottom developed last. The earliest types of life—bacteria—appeared on Earth almost 4 billion years ago as single-celled
organisms with no internal partitions. The “is alive” attribute listed in the box at the top—the most general class—
endured and became an attribute common to all classes below it.
About 2.3 billion years ago, a nucleus and other components appeared inside cells, creating more sophisticated
organisms called Eukaryotes. About 1.3 billion years ago, the first animals appeared. They had more than one cell, and
they were vascular (had containers and conveyors like arteries and veins). About 510 million years ago, some of the
animals (vertebrates) developed backbones and braincases. About 325 million years ago, the first reptiles appeared.
Then, about 245 million years ago, the first mammals appeared. Thus, there is a correspondence between (1) the
classification of biological attributes and (2) their sequence of development.
It’s useful to identify a similar correspondence in object-oriented programming : (1) A classification hierarchy organizes a
program’s attributes. (2) A generic-to-specific development sequence organizes our implementation of those attributes.
A generic-to-specific development sequence organizes our implementation of those attributes. It’s good design practice
to start with a relatively simple and generic implementation and add specializations and complexity in subsequent
design cycles. You’ll see some examples of this later on.
With composition, certain classes contain other classes, but with inheritance, there’s no such containership. For
example, in Figure 13.8, Animal is above Mammal, but an animal does not contain a mammal. Rather, animal is a generic
type, and mammal is a specialized version of animal.
Each descendant type of organism inherits some attributes from its ancestors and adds some new attributes of its own.
Ideally, the characteristics associated with each type high in the hierarchy should be just those attributes that are
“conserved”—actually inherited by all types descended from that type. Thus, ideally, any type at the bottom of the
hierarchy inherits all of the attributes associated with all types above it. For example, mammals have mammary glands
and hair. And, because mammals are vertebrates, they inherit the vertebrate attributes of having a backbone and a
braincase. And, because mammals are also animals, they also inherit the animal attributes of having more than one cell
and being vascular. And, because mammals are also eukaryotes, they also inherit the eukaryote attribute of having a
nucleus in each cell. The types at the very bottom of a biological inheritance hierarchy do not appear in Figure 13.8,
because the complete hierarchy is too big to display in one figure. What’s actually at the bottom are species, like Homo
sapiens (human beings). In nature, reproduction is possible only among members of the same species. Similarly, in an
ideal OOP computer program, the only realizable (instantiable) types are the types at the very bottom of inheritance
hierarchies. Ideally, all types above instantiable types are abstract types. In the next chapter, you’ll learn how you can
use Java’s abstract keyword to prevent the instantiation of abstract types. Organizing an inheritance hierarchy so that all
realizable (instantiable) types appear only at the lowest level (the leaves of a hierarchical tree) minimizes duplication,
and it minimizes maintenance and enhancement labor.
UML Class Diagrams for Inheritance Hierarchies
Figure 13.9 shows a UML class diagram for an inheritance hierarchy that keeps track of people associated with a
department store. The top class, Person , is generic. It contains data and methods that are common to all classes in the
hierarchy. Classes below the top class are more specific. For example, the Customer and Employee classes describe
specific types of people in the department store. Because there are two distinct types of store employees, the Employee
class has two subordinate classes for the two types—the FullTime class for full-time employees and the PartTime class
for part-time employees.
Within an inheritance hierarchy, lower classes inherit upper classes’ members. Thus, the Employee and Customer classes
inherit name from the Person class. Likewise, the FullTime and PartTime 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 inherit name from the Person class. Within an inheritance hierarchy, classes are
linked in pairs. Can you identify the linked pairs in Figure 13.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 considered 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 additional variables and/or methods inside the subclass’s
definition. For example, in Figure 13.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-abovesubclass 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 class diagrams use a solid line and a hollow arrow for
inheritance relationships, with the arrow pointing to the superclass. In Figure 13.9, note how the arrows do indeed point
to the superclasses. Inheritance Terminology Unfortunately, the terms superclass and subclass can be misleading. The
“super” in superclass seems to imply that superclasses have more capability, and the “sub” in subclass seems to imply
that subclasses have less capability. Actually, it’s the other way around—subclasses have more capability. Subclasses can
do everything that superclasses can do, and more. For the most part, we’ll stick with the terms superclass and subclass
since those are the formal terms used by the designers of the Java language, but be aware that there is alternative
terminology. Programmers often use the terms parent class or base class when referring to a superclass. And they often
use the terms child class or derived class when referring to a subclass. The parent-child relationship between classes is
important because it determines inheritance. With a human parent-child relationship, the child normally inherits
physical features from the parent. 1 The class parent-child relationship parallels the human parentchild relationship. But
with a class parent-child relationship, the child doesn’t inherit money; instead, it inherits the variables and methods
defined in the superclass. There are two more inheritance-related terms that you should be aware of. An ancestor class
refers to any of the classes above a particular class in an inheritance hierarchy. For example, in Figure 13.9’s inheritance
hierarchy, Employee and Person are the ancestors of FullTime . A descendant class refers to any of the classes below a
particular class in an inheritance hierarchy. For example, in Figure 13.9’s inheritance hierarchy, Employee , Customer ,
FullTime , and PartTime are descendants of Person . Benefits of Inheritance Long before reading this chapter, you were
already convinced of the benefit of modeling your programs with classes, right? (In case you need to be reminded why
you love classes so much, it’s because classes allow you to encapsulate things.) So you should be able to see the benefit
of having a Customer class and also an Employee class for a department store program. OK, having separate Customer
and Employee classes is good, but why stir up trouble and give them a superclass? If there’s no superclass for the
Customer and Employee classes, then the things common to customers and employees would have to be defined in
both classes. For example, you’d need a name instance variable and a getName method in both classes. But redundant
code is almost always a bad idea. Why? With redundant code, debugging and upgrading chores are more tedious. After
fixing or improving the code in one place, the programmer must remember to fix or improve the code in the other place
as well. In Figure 13.9, notice that classes at different levels in the hierarchy contain different instance variables, and
they have different methods (although Employee and FullTime both have a display method, the methods are different;
that is, they behave differently). There is no functional duplication, and there is maximal code reusability . Code
reusability is when you have code that provides functionality for more than one part of a program. Putting common
code from two classes into a superclass is one example of code reusability. Code reusability can also take place when
you want to add a significant chunk of functionality to an existing class. You might want to implement the functionality
by adding code directly to the existing class. But suppose the class works perfectly, and you’re scared to touch it for fear
of messing it up. Or maybe your know-it-all co-worker wrote the class, and you don’t want to risk getting him or her riled
up over code modi- fications. No problem. Extend the class (that is, create a subclass) and implement the new
functionality in the extended class. You’ve seen that inheritance gives rise to code reusability, and now you should be
properly convinced of the benefits of code reusability. Another benefit of inheritance is that it gives rise to smaller
modules (because classes are split into superclasses and subclasses). In general, smaller modules are good because
there’s less code to wade through when searching for bugs or making upgrades.
Person
-name: String
+Person
Person name : String)
*getName(): String
Employee
-id:int
Customer
address : String
set Address address: String): vold
getAddress(): String
Employee
+Employee name : String, id int)
display:void
Part
Time
hourly Wage: double
Full Time
-salary: double
+FullTime)
+Full Time name : String, id: ini, salary: double)
display:void
gure 13.9 UML dass diagram for a person class inheritance hierarchy
Organism
is alive.
Prokaryote
Has one cell with no nucleus
Pukaryote
Each cell has nucleus.
Bacteria
Normal
Archaea
Extreme
Plant
Has more than one cell.
Is photosynthetic.
Animal
Has more than one cell
Is vascular
Arthropod
Has exoskeleton
Is segmented
Vertebrate
Has backbone.
Has braincase.
Reptile
Lays.
Has scales.
Mammal
Has mammary glands.
Has hair.
Figure 13.8 Biological example of a classification or inheritance hierarchy