CS-2851 Dr. Mark L. Hornick 1 Stacks and Queues Behavior vs. Structure

CS-2851 Dr. Mark L. Hornick 2 The Stack data structure The semantics (behavior) of a Stack is defined as follows: 1. Elements can only be inserted and removed from the front of a Stack This is known as Last-In, First-Out (LIFO)  Less commonly: First-Out, Last-In (FOLI) 2. Random-access is not defined – you cannot access the “middle” of the Stack No get(index) behavior No add(index, element) behavior

CS-2851 Dr. Mark L. Hornick 3 Stack – behavioral methods Principal methods that define behavior: 1. push() – place an element on (top of) the stack 2. pop() – return and remove an element from the (top of the) stack 3. peek() – return the top element of the stack Without removing (popping) it The naming for the structure and the methods is an analogy for how the data elements within the structure are accessed

CS-2851 Dr. Mark L. Hornick 4 What is the best way to implement a Stack? 1. Derive from ArrayList? Advantages? Disadvantages? 2. Derive from LinkedList? Advantages? Disadvantages? Does the internal implementation really matter as long as the resulting collection behaves like a Stack?

CS-2851 Dr. Mark L. Hornick 5 JCF implementation of Stack extends Vector …with the 3 methods necessary for Stack behavior (push, pop, peek) The extended Stack interface conforms to the idea of the stack abstraction, but… it is derived from Vector (like an ArrayList, but less efficient!) All Vector methods are inherited by Stack Thus there are methods to access the interior of the stack which violates the concept of a stack! So a JCF Stack is not a “pure” stack

CS-2851 Dr. Mark L. Hornick 6 Queue data structure Once again: an ordered collection of elements Classical semantics (behavior): 1. Elements can only be inserted at the back and removed from the front of the collection Alternately: inserted at the front and removed from the back 2. This is known as First-In, First-Out (FIFO)

CS-2851 Dr. Mark L. Hornick 7 Queue – behavioral methods offer() – place an element at the back of the queue poll() or remove() – return and remove an element from the front of the queue poll() returns null if the queue is empty remove() throws an exception if the queue is empty peek() or element() – return (without removing) the element at the front of the queue peek() returns null if the queue is empty element() throws an exception if the queue is empty

CS-2851 Dr. Mark L. Hornick 8 JCF Queue is an Interface Unlike Stack, there is no implementation of Queue by itself. The interface just declares the methods that a class implementing Queue would have Queue extends the Collection interface: public interface Queue extends Collection { boolean offer(E o); // add to queue E element(); // get w/o remove E peek(); // get w/o remove E poll(); // get w/ remove E remove(); // get w/ remove What does this imply? What behavior does a Collection have?

CS-2851 Dr. Mark L. Hornick 9 JCF definition of Queue interface is weird The Queue interface conforms to the idea of the queue abstraction, but it is extended from Collection, and so All Collection methods must be implemented by anything that implements Queue There will be methods to access the interior of the queue which violates the queue abstraction ! So you wouldn’t have a true queue

CS-2851 Dr. Mark L. Hornick 10 What is the best way to implement a Queue? 1. Derive from ArrayList? Advantages? Disadvantages? 2. Derive from LinkedList? Advantages? Disadvantages?

CS-2851 Dr. Mark L. Hornick 11 More weirdness: LinkedList implements the Queue interface! So LinkedList is a Collection which is also a List which is also a Queue (and is also a Deque…) What does this imply? LinkedList behaves like them all!