Problem of the Day  What do you get when you cross a mountain climber and a grape?

Problem of the Day  What do you get when you cross a mountain climber and a grape?  Nothing, you cannot cross a scalar.

CSC 212 – Data Structures

Rest of the Year

ADTs Mean Interface s  Each ADT is defined by single Interface  Guarantees methods exist & what they should do  But classes are free to implement however they want  Programmer knows from the interface :  Each of the method signatures  Value returned by the method  The effects of the method’s actions  Why Exception s thrown by method

View of an ADT IOU

You Other Coder IOU

View of an ADT You Other Coder IOU ADT

 ADTs must remain abstract  Any implementation okay, if it completes methods  Could implement an ADT with: Implementing ADT

 ADTs must remain abstract  Any implementation okay, if it completes methods  Could implement an ADT with:  Array Implementing ADT

 ADTs must remain abstract  Any implementation okay, if it completes methods  Could implement an ADT with:  Array  ArrayList Implementing ADT

 ADTs must remain abstract  Any implementation okay, if it completes methods  Could implement an ADT with:  Array  ArrayList  Trained monkeys Implementing ADT

 ADTs must remain abstract  Any implementation okay, if it completes methods  Could implement an ADT with:  Array  ArrayList  Trained monkeys  College students Implementing ADT

Is an array an ADT?

 Arrays are very specific implementation  Single & multiple dimensional versions exist…  … but implementation impossible except with array  No trained monkeys could do same work  Arrays also do not specify functionality  No standard way to access or use data  In fact, there is no interface serving as guarantee! Why Not an ADT?

Implementation vs. ADT ImplementationADT

 Superinterface for all our ADTs  Define methods common to all data structures  Access & usages patterns differ with each ADT Collection Classes

 Superinterface for all our ADTs  Define methods common to all data structures  Access & usages patterns differ with each ADT public interface Collection { public int size(); public boolean isEmpty(); } Collection Classes

 Superinterface for all our ADTs  Define methods common to all data structures  Access & usages patterns differ with each ADT public interface Collection { public int size(); public boolean isEmpty(); } Collection Classes

 Superinterface for all our ADTs  Define methods common to all data structures  Access & usages patterns differ with each ADT public interface Collection { public int size(); public boolean isEmpty(); } Collection Classes

 Awwww… our first collection class  Works like PEZ dispenser:  Add by pushing data onto top  Pop top item off to remove impossible  Accessing other values impossible  Top item only is available  Cheap plastic/private fields get in way Stacks

 Awwww… our first collection class  Works like PEZ dispenser:  Add by pushing data onto top  Pop top item off to remove impossible  Accessing other values impossible  Top item only is available  Cheap plastic/private fields get in way Stacks

 Awwww… our first collection class stack  Works like stack of books (or coins, rocks, …)  Add by pushing data onto top  Pop top item off to remove impossible  Accessing other values impossible  Top item only is available  Gravity’s pull/private fields get in way Stacks

 Awwww… our first collection class stack  Works like stack of chips (or coins, rocks, …)  Add by pushing data onto top  Pop top item off to remove impossible  Accessing other values impossible  Top item only is available  Cardboard tube/private fields get in way Stacks

Applications of Stacks  Stacks are used everywhere  Back & Forward buttons in web browser  Powerpoint’s Undo & Redo commands  Methods’ stackframes used during execution  Java uses stacks to execute operations in program

 Defines two vital methods…  push(obj)  add obj onto top of stack  pop()  remove & return item on top of stack  … an accessor method…  peek()  return top item (but do not remove it)  … and Collection ’s methods…  size()  returns number of items in stack  isEmpty()  states if stack contains items Stack ADT

 ADT also uses shared exception public class EmptyCollectionException extends RuntimeException { public EmptyCollectionException(String err){ super(err); } }  EmptyCollectionException is unchecked  Need not be listed in throws, but could be  Unchecked since there is little you can do to fix it  try-catch not required, but can crash program More Stack ADT

public interface Stack extends Collection { public E peek() throws EmptyCollectionException; public E pop() throws EmptyCollectionException; public void push(E element); }  Any type of data stored within a Stack  Generics enable us to avoid rewriting this code  Minimum set of exceptions defined by interface  Classes could throw more unchecked exceptions Stack Interface

Using Stack

Your Turn  Get into your groups and complete activity

For Next Lecture  Read 3.3 – 3.4 for Wednesday’s class  Must we write Stack for each type of data?  I HATE typecasts; can we avoid them forever?  Eliminating errors by compiler, where do I sign up?  Programming assignment #1 also on Angel  Pulls everything together and shows off your stuff  Please get it started, since due in 3 weeks