Version 4.1¹

Handouts:

• Telephone.java, CellPhone.java, VoiceMail.java, Tester.java, UML classdiagram (diagram needs improvement)
• LightUser.java (illustrates dynamic dispatch)

Highlights

Inheritance means that one class is "just like that other one, except ...". At least that's Drake's initial definition (p. 67); but we should really add that inheritance means one class is a kind of another, for example, as Dog is a kind of Mammal. Class hierarchies in programming originate from classification, which is a very natural and useful way of structuring thought.

This is a very important feature of OOP, right up there with objects as bundles of data and functions.

3.1 Extending a Class

A. Example 1

This example develops classes representing a simple telephone, a cell phone, and a voice mail service, as shown in the UML class diagram (needs improvement):

The CellPhone class inherits from Telephone and adds features: the ability to set a ring tone, and voice mail. Voice mail is implemented by delegating messages (method calls) to a VoiceMail object. There is also a Tester class for demonstrating the other three.

• Source code:
  • Telephone.java
  • CellPhone.java
  • VoiceMail.java
  • Tester.java

B. Distinction Between Overriding and Overloading

Here's a method call:

a.meth(b, c)

Overriding is about a.

• Method dispatch depends on the actual (not declared) type of a, the "receiver of the message".
• Dispatched at run time.
• Compare C++ "virtual methods" — all Java non-static methods are "virtual."
• Methods have same name and signature, but are in different classes.
• Usually, one is a subclass of the other. But we can still have polymorphism even without inheritance—same name and signature, method defined in two or more classes not related by inheritance.

Overloading is about (b, c).

• Method dispatch depends on the declared (not actual) number and types of the method arguments.
• Dispatched at compile time.
• Methods have same name, different signatures, and may be in the same or different classes.
• A common error is to overload a method when you intend to override it.
• Example:

  • The Object class has the method

    public boolean equals (Object that);  // method 1

  • If in the Telephone class I had defined

    public boolean equals (Telephone that); // method 2

    then I would have been overloading, not overriding.

  • In the statement

    x.equals(y);

    method 2 will be run if the declared type of y is Telephone and the actual type of x is Telephone; otherwise method 1 runs.
  • So if y is declared as Object but is actually a Telephone, we don't get the desired result.

  • If y is declared Object and is not a Telephone, what happens?

C. Overriding by Specialization

• Sometimes we want to override a method or constructor by adding something to what the superclass's method or constructor does.
• super(num) (see CellPhone constructor) calls the constructor of its superclass (Telephone) with one argument.

• Calling the superclass constructor must be the first action of the constructor of the subclass. We can call a constructor with arguments:

  super(a, b, c);

  If we don't write a call to a superclass constructor, the compiler will insert super() (with no arguments) for us, as the first statement.
  • Why?

• Similarly, in the CellPhone method ring we see

  super.ring()

  This calls the method ring from the superclass, Telephone, avoiding the need to repeat the same statements here.

  Calling super allows the subclass's method or constructor to use what the superclass has defined, but then add to it or embellish it in some way. But for a method, it does not have to be the first statement.

D. Subclasses and Interfaces

Drake: "Extending a class is similar to implementing an interface." (p. 69, last paragraph).

• Agree or disagree?
• He describes two differences, but what's the similarity?

E. Example 2: Light and ColoredLight

• See: class diagram Fig. 3-5 p. 72; Light class Fig. 3-3 p. 70; ColoredLight class Fig. 3-4 p. 71.
• What methods/fields does ColoredLight inherit?
• Which ones does it override?
• What new methods and fields does it declare?
• Which inherited fields and methods are not directly accessible in ColoredLight? And how are they accessed?

F. Polymorphism and Inheritance

(p. 72) We can write either

Light bulb = new Light();

or

Light bulb = new ColoredLight();

and either way, we can safely write

bulb.setOn(false);

but how it behaves depends on what type of object it (bulb) is. Dynamic dispatch here. [Note: we could even let the actual class be determined by user input at run time. Of course, the compiler cannot predict what the user will input!

• Example: LightUser.java

G. Chains of Inheritance

Subclasses can have subclasses; see FlashingColoredLight in Fig. 3-7, 3-6, pp. 74, 73.

Inheritance is transitive: If class A defines method foo which is inherited by subclass B, and if C is a subclass of B, then C also inherits foo.

H. Is-a and Has-a

• "B is subclass of A" means B is a kind of A; e.g., BlueWhale is a kind of Whale.
• Having is different from being.
• In the phones example, a cell phone is a telephone; it has a voicemail.
• A WhaleFarm (if there could be such a thing!) would have whales, but would not be a Whale, so we shouldn't try to represent it as a subclass of Whale.
• Instead, a field or fields in the WhaleFarm class could reference the Whales on the farm.
• Another example: LightString, Fig. 3-8 on pp. 74-75.
  • Notice the field bulbs, an array of Light.
  • Notice how setOn operates by delegating the action to the bulbs.
  • Both delegation and inheritance promote "software re-use." But they are different.
• Class diagram, Fig. 3-9, p. 76. Notice the different arrow types used for is-a and has-a.

The remaining two sections cover special topics related to inheritance: the Object class, packages, and access levels.

3.2 The Object Class

(Already covered in chapter 2)

Every object is an Object!

Object is the default superclass in Java; i.e., if we don't declare that a class "extends something" then "extends Object" is implicit.

Some methods of the Object class are generally useful, either "as is" or by overriding:

• public boolean equals (Object that) Behaves just like == (so if you want different behavior, you override it)

• public String toString() returns a string of the form "〈class〉@〈address〉"

• If we do not override the equals and toString methods, these are the behaviors we get.

3.3 Packages and Access Levels

A. Packages

• Packages are collections of classes and interfaces; usually a package has a name. Everything I say below about classes in packages applies to interfaces as well.
• Packages support large-scale software development by providing "namespaces". Within a package, class names must be unique. But the same class name may be used in different packages to identify different classes. The names do not "collide", because the package system provides another layer of encapsulation.

• A class in a named package has a "full name" (or "fully qualified name") which is completely unambiguous, e.g., java.util.Scanner

  • Within the package we can refer to the class by its short name (Scanner).

  • Outside the package, we must use the fully-qualified name, except:

    • Classes in package java.lang
    • Classes in the default package, which has no name

    • After the class or its package is imported into the current file: either

      import java.util.Scanner;

  or

  import java.util.*;

• Creating a package:

  • Write the package declaration at the beginning of each file in the package:

    package graphics;

  • Place the files in a directory according to their package name (files in the "graphics" package go in the "graphics" directory)

  • Compound package names e.g. java.awt.event:

    • Each component requires a directory: "java/awt/event"
    • Importing java.awt.* does not import classes in java.awt.event.* !

• Can we extend a class that's in another package?

  • Certainly. We do this routinely, for example, when we write a subclass of java.lang.Object (implicitly or explicitly). We can do this for other packages and classes as well.

B. Access Levels

Access modifiers are Java reserved words that describe fields and methods (also classes and interfaces!) and provide information hiding. There are four access levels and three access modifier keywords:

• private = accessible only within the class
• "package" accessible = accessible within the package. "package" is not a Java access modifier keyword (it is a keyword, but used to declare a package, not an access level). Package accessibility is the default access level, which we get simply by not declaring one of the other three levels (public, private, or protected), except in an interface, where the default is public.
• protected = accessible within the package and to descendants (subclasses, direct or indirect) of the class.
  • Drake recommends defining protected accessors and mutators, rather than protected fields, to prepare a class for extension to subclasses. This ensures that the fields are accessed correctly by the subclasses. Arguable.
• public = accessible everywhere.
• Not every OOP-language provides access levels: e.g., Python and Common Lisp do not.

Footnotes