I started with a simple example. We've seen how to use an ArrayList which has operations like add, get and size, as in:
List<String> list = new ArrayList<String>();
list.add("how");
list.add("are");
list.add("you?");
System.out.println("list = " + list);
which produces the following output:
list = [how, are, you?]
I posed the following question. Suppose that you want a list that behaves
slightly differently? In particular, you'd like it to be the case that every
time that add is called, it actually adds two of the value to the list.
So it should have a kind of stuttering effect. In all other respects, it
should behave like a normal list.How would you make this change? The ArrayList class is part of the Java class libraries, so it would not be easy to change it. But that isn't a problem when you work in an object oriented language. There is a mantra that you'll hear in the object-oriented programming community that we want "additive--not invasive--change." Programmers are very used to the idea of doing surgery on existing code. We call that "invasive change" because it involves cutting open an existing class and rearranging it. This is like doing surgery on a person. Sometimes you have no choice but to perform surgery, but it can be very traumatic to do so. As a result, we want to avoid it if we can.
Inheritance provides a great mechanism for avoiding surgery. We can construct a new class called StutterList that inherits from ArrayList:
public class StutterList<E> extends ArrayList<E> {
...
}
Just with this simple inheritance declaration, we get a class that behaves just
like an ArrayList. Now we can say what is different about our version. We
want this version of the list to add everything twice. We can easily define
that in terms of the existing "add" in the super class:
public class StutterList<E> extends ArrayList<E> {
public boolean add(E value) {
super.add(value);
super.add(value);
return true;
}
}
Note: the add method in ArrayList returns a boolean value to indicate whether
the add was successful, so we have to replicate that behavior in our version.
This is all you have to do to make a variation that adds twice. Remember that
when you inherit, you have the option to override a method. In this case, we
are overriding the add method to give it a different behavior. But you still
have access to the method you are overriding by using the "super" keyword (in
this case, calling super.add).Now we have a class that we can use in place of an ArrayList that will have the stuttering behavior we wanted. For example, if we say:
List<String> list = new StutterList<String>();
list.add("how");
list.add("are");
list.add("you?");
System.out.println("list = " + list);
we get the following output:
list = [how, how, are, are, you?, you?]
The idea is that inheritance is very good at capturing variations. Using
inheritance we can make a minor change to an existing class without changing
the original class (additive--not invasive--change).As a second example, I said to suppose that you wanted to have a Point object that remembers how many times it has been translated. How can you do that?
The answer will involve inheritance again. But this time it is not as simple as defining a new method. We'll also need a new data field. To remember the number of times it has been translated, the point will need an integer counter. So it will look like this:
import java.awt.*;
public class MyPoint extends Point {
private int count;
...
}
I don't have a good short name for this class. I don't want to call it
PointThatRemembersHowManyTimesItHasBeenTranslated. So instead I just called it
"MyPoint." We'll want to override the translate method. It can call the
original translate method because we'll still want to do that original
behavior, but we can also increment our counter:
public void translate(int dx, int dy) {
count++;
super.translate(dx, dy);
}
So now we have a data field to remember this and we've modified the translate
method to increment the counter each time it is called. The problem is that
this is a private data field that we can't see from the outside. So if we want
to allow someone to actually see the value of the counter, we'd have to add a
"getter" method:
public int getTranslateCount() {
return count;
}
This provides a pretty good version of the class, although there are a few
details that we still have to work out. Here's what we have so far:
import java.awt.*;
public class MyPoint extends Point {
private int count;
public void translate(int dx, int dy) {
count++;
super.translate(dx, dy);
}
public int getTranslateCount() {
return count;
}
}
Someone suggested that we need to think about the initialization of the
counter. I said that we certainly need to think about it, but in this case,
we're okay. Remember that Java initializes all data fields to the
0-equivalent. So the counter will be initialized to 0. But the details I'm
thinking about do have to do with the constructing of a Point.So I mentioned to people a detail of inheritance that we haven't yet discussed. What do you get when you inherit from another class? You inherit the state and behavior of the other class. But not entirely. You inherit most methods from the class that you extend, but not all of them. Someone said "constructors" and I said, "That's right." You don't inherit constructors from a class that you extend.
I decided to use this as an opportunity to review the details of constructors and to discuss how inheritance factors into this. So I asked people what Java does when you don't define any constructors. The answer is that Java defines one for you. We refer to it as the "default" or "paren paren" or "zero argument" constructor. For our class called MyPoint, it would be as if we had included the following method in the class:
public MyPoint() {
// nothing to do
}
But this would be the only constructor for the class. In particular, we
wouldn't be able to say something like:
Point p1 = new MyPoint(8, 17);
I then mentioned that every constructor makes a call on a superclass
constructor, whether you do so explicitly or not. The syntax for calling a
superclass constructor is very similar to the syntax for one constructor
calling another, except for the fact that you use the keyword "super" instead
of the keyword "this". For example, if you want to call the default
constructor of the superclass, you say:
super();
We have been writing classes for a long time without including such calls. The
reason that works is that if you don't call a superclass constructor, then Java
does it for you. And by default it calls the default constructor. So if you
don't include a call on the superclass constructor, Java will insert the call
above for you.That means that our MyPoint constructor isn't quite as empty as we had thought. It really does the following:
public MyPoint() {
super();
}
Remember that Java inserted this constructor for us because we didn't define
one of our own. What would happen if the Point class did not have a default
constructor? In that case, we would have gotten a weird error message:
MyPoint.java:3: cannot find symbol
symbol : constructor Point()
That would seem like an odd error message because we never call Point()
anywhere in our code. But it makes sense when you understand that Java is
doing it for us. Without a constructor, Java will give us a default
constructor. And since we didn't say how to call a superclass constructor, it
makes the call super().The Point class actually does have a default constructor, so we don't get this message. But it's important to remember that this will occur. Many classes do not have a default constructor, and then you must call a superclass constructor.
In our case, we want to have a constructor that takes two integers that specify x and y. Our class doesn't keep track of x and y, that's what the Point class does. So all we want to do is to pass the values up the chain to the Point class' constructor that takes two arguments. We can also initialize the counter just to be clear:
public MyPoint(int x, int y) {
super(x, y);
count = 0;
}
Now we can construct MyPoint objects with two ints. Unfortunately, now we can
no longer construct the origin by asking for a "new MyPoint()". Java defines a
default constructor if you don't define any of your own. But if you have even
one constructor in your class, then Java assumes that you know what you're
doing and that you would have defined a default constructor if you wanted one.
So if we really want that for the MyPoint class, we have to specifically
include it. In this case, we can call the two-argument constructor in the
MyPoint class:
public MyPoint() {
this(0, 0);
}
Putting it all together, here is the definition of MyPoint:
import java.awt.*;
public class MyPoint extends Point {
private int count;
public MyPoint() {
this(0, 0);
}
public MyPoint(int x, int y) {
super(x, y);
}
public void translate(int dx, int dy) {
count++;
super.translate(dx, dy);
}
public int getTranslateCount() {
return count;
}
}
I pointed out that in a previous lecture we wrote an add method for the IntTree
class that would allow you to build a binary search tree of integers. You
might want to build other kinds of binary search trees with different kinds of
data and you wouldn't want to make many copies of essentially the same code
(one for integers, one for Strings, etc). Instead, you want to write the code
in a more generic way.I showed a client program for a new version of the class that I call SearchTree that will work for any class that implements what is known as the Comparable interface. The new class is a generic class, so it would be better to describe it as SearchTree<E> (for some element type E). The client code constructs a SearchTree<String> that puts words into alphabetical order and a SearchTree<Integer> that puts numbers into numerical order.
I then went over some of the details that come up in converting the IntTree binary search tree code into the generic SearchTree code. I mentioned that programming generic classes can be rather tricky. I'm showing this example so that you can see how it's done, but I wouldn't expect you to implement a generic class on your own. You should, however, know how to make use of a generic class or interface. For example, we might ask you to use a LinkedList<String> or we might ask you to implement the Comparable<T> interface, but you won't have to write a generic class from scratch.
We started by writing a node class for the tree. We found it was very tedious because we had to include the <E> notation in so many different places:
public class SearchTreeNode<E> {
public E data;
public SearchTreeNode<E> left;
public SearchTreeNode<E> right;
public SearchTreeNode(E data) {
this(data, null, null);
}
public SearchTreeNode(E data, SearchTreeNode<E> left,
SearchTreeNode<E> right) {
this.data = data;
this.left = left;
this.right = right;
}
}
Then I asked about the SearchTree class. Like our IntTree, it should have a
single field to store a reference to the overall root, so we wrote the
following:
public class SearchTree<E> {
private SearchTreeNode<E> overallRoot;
...
}
We then looked at how to convert the IntTree add method into a corresponding
generic method. The syntax makes it look fairly complicated, but in fact, it's
not that different from the original code. Remember that our IntTree add
looks like this:
public void add(int value) {
overallRoot = add(value, overallRoot);
}
private IntTreeNode add(IntTreeNode root, int value) {
if (root == null)
root = new IntTreeNode(value);
else if (value <= root.data)
root.left = add(root.left, value);
else
root.right = add(root.right, value);
return root;
}
If we just replace "int" with "E" and replace "IntTreeNode" with
"SearchTreeNode<E>", we almost get the right answer:
public void add(E value) {
overallRoot = add(overallRoot, value);
}
private SearchTreeNode<E> add(SearchTreeNode<E> root, E value) {
if (root == null)
root = new SearchTreeNode<E>(value);
else if (value <= root.data)
root.left = add(root.left, value);
else
root.right = add(root.right, value);
return root;
}
The problem is that we can no longer perform the test in this line of code:
else if (value <= root.data)
Instead, we have to use a call on the compareTo method:
else if (value.compareTo(root.data) <= 0)
We have to make one more change as well. All that Java would know about these
data values is that they are of some generic type E. That means that as far as
Java is concerned, the only role it knows they can fill is the Object role.
Unfortunately, the Object role does not include a compareTo method because not
all classes implement the Comparable interface. We could fix this with a cast
and that is what you'll find in most of the code written by Sun:
else if (((Comparable<E>) value).compareTo(root.data) <= 0)
Another approach is to modify the class header to include this information. We
want to add the constraint that the class E implements the Comparable
interface. We specify that by saying:
public class SearchTree<E extends Comparable<E>> {
...
}
It's odd that Java has us use the keyword "extends" because we want it to
implement the interface, but that's how generics work in Java. If we are
defining a class, we make a distinction between when it extends another class
versus when it implements an interface. But in generic declarations, we have
just the word "extends", so we use it for both kinds of extension.