(^336) | Inheritance, Polymorphism, and Scope
members and aren’t inherited). We repeat this process in the third column, adding the mem-
bers ofJComponent. The process continues until finally, we write the members ofObject(ex-
cluding its constructors) in the last column. Of course, with more than 400 methods, this
process is quite tedious, especially given that we aren’t interested in the vast majority of
them. In practice, we just write down the ones that pertain to the problem at hand.
Overriding
A careful examination of theJComponentclass reveals that it defines a method called
getUIClassID. We don’t use this method in this book, but it illustrates another aspect of Java
class hierarchies. Looking back down the hierarchy, we find thatJTextFieldrede-
fines (overrides)getUIClassID, substituting its own version ofgetUIClassID. Thus, in
our lists of methods, we would cross off theJComponentmember name to indicate
that it is redefined byJTextField.
Together, the columns in the complete table would tell us every member that
is available in the class JTextField. When we first looked at the documentation for
JTextField, it appeared that the class had just 33 members. Now, however, we can
identify more than 400 members. This example illustrates the power of using in-
heritance in a hierarchy of classes. Just as the architect can save effort by defin-
ing a hierarchy of building parts, we can save ourselves a lot of work by using
inheritance.Hiding
In ourJTextFieldexample, we considered only inheritance of methods. In reality,
fields may also be inherited through the hierarchy. When a derived class defines
a field with the same name as one in its superclass, the field in the derived
classhidesthe one in the superclass. Java also distinguishes the case of over-
riding astatic(class) method with another class method as a form of hiding.
The termoverridingtechnically applies only to instance methods.
If you look at the JTextFieldhierarchy carefully, you would notice that nothing is deleted
as a result of inheritance (except constructors). Java does not provide any way to remove a
member that is inherited. We can cover over a member with a replacement member, but we
can’t delete it. This is an aspect of the philosophy of object-oriented design: As we go deeper
in the hierarchy, we add or change functionality, but we do not lose functionality. In object-
oriented design, a derived class is always an extension of its superclass.
For example, we would say that a JTextFieldis aJTextComponent. In object-oriented de-
sign, a fundamental concept is the “is a” relationship between a derived class and its su-
perclass. A derived class is aform of its superclass. The closest that we can get to deleting
a member of a superclass in a derived class is to override it or hide it with a member of the
same name that does nothing. For example, we could override a method with a version that
simply returns null. This approach would be considered poor programming practice, how-
ever.Override To provide an
instance method in a derived
class that has the same form of
heading as an instance method
in its superclass. The method in
the derived class redefines
(overrides) the method in its su-
perclass. We cannot override
class methods.
Hide To provide a field in a de-
rived class that has the same
name as a field in its superclass;
to provide a class method that
has the same form of heading as
a class method in its superclass.
The field or class method is said
to hide the corresponding com-
ponent of the superclass.