Based on slides by Alyssa Harding & Marty Stepp CSE 143 Lecture 9 Interfaces Stacks, Queues Based on slides by Alyssa Harding & Marty Stepp

ArrayIntList and LinkedIntList classes ArrayIntList and LinkedIntList both store lists of ints. Both classes are very similar in terms of WHAT they can do. Both classes have these methods in common: public int size() {...} public int get(int index) {...} public String toString() {...} public int indexOf(int value) {...} public void add(int value) {...} public void add(int index, int value) {...} public void remove(int index) {...} The two classes differ in HOW they implement these methods 2

An IntList interface } // Represents a list of integers. public interface IntList { public int size(); public int get(int index); public String toString(); public int indexOf(int value); public void add(int value); public void add(int index, int value); public void remove(int index); } public class ArrayIntList implements IntList { ... public class LinkedIntList implements IntList { ...

Interfaces as Type Anywhere we want a IntList, we can use an ArrayIntList or a LinkedIntList: IntList list1 = new ArrayIntList(); IntList list2 = new LinkedIntList(); Declare the variable with the most abstract type possible This lets the compiler know that our variable is guaranteed to have the functionality of an IntList Instantiate the variable with the implementation type This lets the compiler know how to perform the methods, as an ArrayIntList or a LinkedIntList. 4

Interfaces as Type However, we cannot create an instance of an Interface IntList list1 = new IntList(); IntList is abstract; cannot be instantiated But we can declare variables, parameters, return types of type IntList (or Arrays or collections of them) 5

“Favor Interfaces” Tip 52 from Joshua Bloch's “Effective Java” "Refer to objects by their interfaces." “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." "The only time you really need to refer to an object's class is when you're creating it.” 6

An Aside: Interfaces vs. Inheritance interface: A list of methods that classes can promise to implement. Inheritance gives you an is-a relationship and code sharing. A Lawyer object can be treated as an Employee, and Lawyer inherits Employee's code. Interfaces give you an is-a relationship without code sharing. A LinkedIntList object can be treated as a IntList but inherits no code. Analogous to non-programming idea of roles or certifications: "I'm certified as a CPA accountant. The certification assures you that I know how to do taxes, perform audits, and do consulting." "I'm a Shape. I know how to compute my area and perimeter."

Abstract Methods All methods in interfaces are abstract methods. abstract method: A header without an implementation. The actual bodies are not specified, because we want to allow each class to implement the behavior in its own way. A class can declare that it "implements" an interface. The class promises to contain each method in that interface. (Otherwise it will fail to compile.) Example: public class Bicycle implements Vehicle { // Implementations for abstract methods // declared in Vehicle interface. ... }

Shape Interface (Section 9.5) // Describes features common to all shapes. public interface Shape { public double area(); public double perimeter(); } Saved as Shape.java public class Circle implements Shape { ... public class Rectangle implements Shape { ...

Interface requirements public class Banana implements Shape { // haha, no methods! } If we write a class that claims to be a Shape but doesn't implement area and perimeter methods, it will not compile. Banana.java:1: Banana is not abstract and does not override abstract method area() in Shape ^

Interfaces + polymorphism Interfaces benefit the client code author. They allow client code to take advantage of polymorphism (the same code is able to work with different types of objects). public static void printInfo(Shape s) { System.out.println("The shape: " + s); System.out.println("area : " + s.area()); System.out.println("perim: " + s.perimeter()); System.out.println(); } Any shape can be passed as the parameter to the method. Shape circ = new Circle(12.0); Shape tri = new Triangle(5, 12, 13); printInfo(circ); printInfo(tri);

Stacks and Queues

Stacks and queues Sometimes it is good to have a collection that is less powerful, but is optimized to perform certain operations very quickly. Today we will examine two specialty collections: stack: Retrieves elements in the reverse of the order they were added. queue: Retrieves elements in the same order they were added. queue stack

Abstract data types (ADTs) abstract data type (ADT): A specification of a collection of data and the operations that can be performed on it. Describes what a collection does, not how it does it We don't know exactly how a stack or queue is implemented, and we don't need to. We just need to understand the idea of the collection and what operations it can perform. (Stacks are usually implemented with arrays; queues are often implemented with a linked list.)

Stacks stack: A collection based on the principle of adding elements and retrieving them in the opposite order. Last-In, First-Out ("LIFO") The elements are stored in order of insertion, but we do not think of them as having indexes. The client can only add/remove the last element added (the "top"). basic stack operations: push: Add an element to the top. pop: Remove the top element. analogy: trays of food at the sizzler

Queues queue: Retrieves elements in the order they were added. First-In, First-Out ("FIFO") Elements are stored in order of insertion but don't have indexes. Client can only add to the end of the queue, and can only remove the front of the queue. basic queue operations: enqueue: Add an element to the back. dequeue: Remove the front element. queue analogy: trays of food at the sizzler