09/22/10
21:29:17 1
12
CS 61B: Lecture 12
Friday, September 24, 2010
Today’s reading: Sierra & Bates, Chapter 8.
ABSTRACT CLASSES
================
An abstract class is a class whose sole purpose is to be extended.
public abstract class List {
protected int size;
public int length() {
return size;
}
public abstract void insertFront(Object item);
}
Abstract classes don’t allow you to create objects directly. You can declare a
variable of type List, but you can’t create a List object.
List myList; // Right on.
myList = new List(); // COMPILE-TIME ERROR.
However, abstract classes can be extended in the same way as ordinary classes,
and the subclasses are usually not abstract. (They can be, but usually they’re
normal subclasses with complete implementations.)
The abstract List class above includes an abstract method, insertFront. An
abstract method lacks an implementation. The purpose of an abstract method is
to guarantee that any non-abstract subclass will implement the method.
Specifically, any non-abstract subclass of List must have an implementation for
the insertFront method.
public class SList extends List {
// inherits the "size" field.
protected SListNode head;
// inherits the "length" method.
public void insertFront(Object item) {
head = new SListNode(item, head);
size++;
}
}
If you were to leave out the implementation of insertFront in SList, the Java
compiler would complain that you must provide one. A non-abstract class may
never contain an abstract method, nor inherit one without providing an
implementation.
Because SList is not abstract, we can create SList objects; and because SLists
are Lists, we can assign an SList to a List variable.
List myList = new SList(); // Right on.
myList.insertFront(obj); // Right on.
What are abstract classes good for? Let’s consider the List class. Although
the List class is abstract, it is an ADT--even without any implementation!--
because it has an interface with public method prototypes and well-defined
behaviors. We can implement an algorithm--for example, a list sorter--based on
the List interface, without ever knowing how the lists will be implemented.
One list sorter can sort every kind of List.
public void listSort(List l) { ... }
In another part of the universe, your project partners can build lots of
subclasses of List: SList, DList, TailList, and so on. They can also build
special-case List subclasses: for example, a TimedList that records the amount
of time spent doing List operations, and a TransactionList that logs all
changes made to the list on a disk so that all information can be recovered if
a power outage occurs. A library catalogue application that uses DLists can
send them to your listSort algorithm to be sorted. An airline database that
uses TransactionLists can send them to you for sorting, too, and you don’t have
to change a line of sorting code. You may have written your list sorter before
TransactionLists were ever thought of.
----------------- The list sorter is built on the foundation of a list
| Application | ADT, and the application is built on the foundation of
----------------- the list sorter. However, it’s the application, and
| not the list sorter, that gets to choose what kind of
| calls list is actually used, and thereby obtains special
v features like transaction logging. This is a big
----------------- advantage of object-oriented languages like Java.
| List Sorter |
-----------------
|
| calls
v
-----------------
| List ADT |
-----------------
