CSE143 Notes for Monday, 1/23/06

        public class IntList {
            private int[] elementData;
            private int size;

            ...

            public void add(int value) {
                ...
            }

            ...
        }

        public class LinkedIntList {
            private ListNode front;

            ...

            public void add(int value) {
                ...
            }

            ...
        }

We have been using this concept for many years in programming. It is traditionally referred to as an Abstract Data Type or ADT:

        A bstract
        D ata
        T ype

        public interface IntList {
            public void add(int value);
            ...
        }

In particular, you can not include data fields in an interface. There is no "state" allowed in an interface. It specifies behaviors only, not how those behaviors are implemented. In fact, as a shorthand, you can think of an interface as specifying the "what" part of an ADT and the implementation as specifying the "how" part. Notice that this interface has the header for the appending add method. But in an interface, we aren't allowed to include an actual implementation of the method. Remember that it is like a hollow class without the actual electronics that make it work. So in place of the curly braces that would normally contain the method definition, we put a semicolon. This is a convention borrowed from C and C++ where this is known as a "function prototype". From the header we know the signature of the method, but that's all we need for the abstraction (the "what" part).

But remember that we have two implementations. We have an array-based implementation that we used to call IntList. Now that we are using the name IntList for the interface, we can change its name to ArrayIntList. We would now define it as follows:

        public class ArrayIntList implements IntList {
            ...
        }

        public class LinkedIntList implements IntList {
            ...
        }

I mentioned that the best analogy I have for interfaces is that they are similar to how we use the concept of certification. You can't claim to be a certified doctor unless you have been trained to do certain specific tasks. Similarly, to be a certified teacher you have to know how to behave like a teacher, to be a certified nurse you have to know how to behave like a nurse, and so on. In Java, if you want to claim to be a certified IntList object, then you have to have several different methods, including an appending add method . Java classes are allowed to implement as many interfaces as they want to, just as a single person might be certified to do several jobs (e.g., both a certified doctor and a certified lawyer).

Because an interface is like a hollow class, you can't create instances of it. For example, given our new IntList interface, we can't say:

        IntList list = new IntList();

        IntList list = new LinkedIntList();

        IntList list = new ArrayIntList();

I then mentioned that this is an idea that has been used throughout the collections classes in Java (the java.util package). I read a short passage from the book "Effective Java" by Joshua Bloch, which I said was one of the most useful books I've read about Java. Joshua Bloch was the primary architect of the collections framework and has influenced much of Sun's work. He now works at Google.

In the collections framework, Bloch was careful to define ADTs with interfaces. For example, there are interfaces for List, Set and Map which are ADTs that we'll be discussing this quarter (we've already been examining the List concept). In addition to the interfaces, there are various implementations of each. For example, ArrayList and LinkedList both implement the List interface. TreeMap and HashMap both implement the Map interface. And TreeSet and HashSet both implement the Set interface.

Bloch's book is written as a series of 57 suggested practices for Java programmers. I have a link to the book and the suggested practices from our class web page (under "useful links"). His item 34 is to "Refer to objects by their interfaces." The passage I quoted was, "you should favor the use of interfaces rather than classes to refer to objects. If appropriate interface types exist, parameters, return values, variables and fields should all be declared using interface types." This last sentence was in bold face in the book, indicating how important Bloch thinks this is, and I've reproduced that here. He goes on to say that, "The only time you really need to refer to an object's class is when you're creating it."

You'll find almost identical language in my assignment writeup for Sieve. I ask you to declare all variables using the Queue interface and say that you should use the LinkedQueue class name only when it is constructed (i.e., only after the word "new"). This is something we're going to be taking points off for when people don't follow the rule because it's an important point to understand about interfaces versus implementations and it is an important style issue, which is why Bloch included it in his book.

Then I discussed two classic data structures known as stacks and queues. The two structures are similar in that they each store a sequence of values in a particular order. But stacks are what we call LIFO structures while queues are FIFO structures:

        stacks        queues

        L-ast         F-irst
        I-n           I-n
        F-irst        F-irst
        O-ut          O-ut

The analogy for queues is to think about standing in line at the grocery store. As new people arrive, they are told to go to the back of the line. When the store is ready to help another customer, the person at the front of the line is helped. In fact, the British use the word "queue" the way we use the word "line" telling people to "queue up" or to "go to the back of the queue".

For a minimal stack, we'd need:

• a way to put a value on the top of the stack (something we call "pushing" a value on the top)
• a way to remove a value from the top of the stack (something we call "popping" the stack)
• and a way to test whether the stack is empty

        public interface Stack<E> {
            public void push(E value);
            public E pop();
            public boolean isEmpty();
            public int size();
        }

For queues, we have a corresponding set of operations but they have different names. When values go into a queue we refer to it as "enqueueing" a value. When values are removed from a queue we refer to it as "dequeueing" a value. So the Queue interface looks like this:

        public interface Queue<E> {
            public void enqueue(E value);
            public E dequeue();
            public boolean isEmpty();
            public int size();
         }

I did not have time to review the example code from handout #12, but I mentioned that we'd be reviewing stacks and queues in section.

Below are links to the interface files and implementation files for stacks and queues:

• Stack.java, the Stack interface
• Queue.java, the Queue interface
• ArrayStack.java, one Stack implementation (we could imagine defining many such implementations)
• LinkedQueue.java, one Queue implementation (we could imagine defining many such implementations)