9.3 Overriding, Interface Inheritance

Overriding

We promised we would implement the methods specified in List61B in the AList and SLList classes, so let's go ahead and do that.

When implementing the required functions in the subclass, it's useful (and actually required in 61B) to include the @Override tag right on top of the method signature. Here, we have done that for just one method.

@Override
public void addFirst(Item x) {
    insert(x, 0);
}

It is good to note that even if you don’t include this tag, you are still overriding the method. So technically, you don't have to include it. However, including the tag acts as a safeguard for you as the programmer by alerting the compiler that you intend to override this method. Why would this be helpful you ask? Well, it's kind of like having a proofreader! The compiler will tell you if something goes wrong in the process.

Say you want to override the addLast method. What if you make a typo and accidentally write addLsat? If you don't include the @Override tag, then you might not catch the mistake, which could make debugging a more difficult and painful process. Whereas if you include @Override, the compiler will stop and prompt you to fix your mistakes before your program even runs.

Interface Inheritance

Interface Inheritance refers to a relationship in which a subclass inherits all the methods/behaviors of the superclass. As in the List61B class we defined in the Hyponyms and Hypernyms section, the interface includes all the method signatures, but not implementations. It's up to the subclass to actually provide those implementations.

This inheritance is also multi-generational. This means if we have a long lineage of superclass/subclass relationships like in Figure 4.1.1, AList not only inherits the methods from List61B but also every other class above it all the way to the highest superclass AKA AList inherits from Collection.

GRoE

Recall the Golden Rule of Equals we introduced in the first chapter. This means whenever we make an assignment a = b , we copy the bits from b into a, with the requirement that b is the same type as a. You can't assign Dog b = 1 or Dog b = new Cat() because 1 is not a Dog and neither is Cat.

Let's try to apply this rule to the longest method we wrote previously in this chapter.

public static String longest(List61B<String> list) takes in a List61B. We said that this could take in AList and SLList as well, but how is that possible since AList and List61B are different classes? Well, recall that AList shares an "is-a" relationship with List61B, Which means an AList should be able to fit into a List61B box!

Exercise 4.1.2 Do you think the code below will compile? If so, what happens when it runs?

public static void main(String[] args) {
    List61B<String> someList = new SLList<String>();
    someList.addFirst("elk");
}

Here are possible answers:

• Will not compile.

• Will compile, but will cause an error on the new line

• When it runs, an SLList is created and its address is stored in the someList variable, but it crashes on someList.addFirst() since the List class doesn't implement addFirst;

• When it runs, and SLList is created and its address is stored in the someList variable. Then the string "elk" is inserted into the SLList referred to by addFirst.