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

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

3. CSC 212 – Data Structures

4. Rest of the Year

6. 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

7. View of an ADT IOU

8. You Other Coder IOU

9. View of an ADT You Other Coder IOU ADT

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

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

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

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

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

15. Is an array an ADT?

17.  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?

18. Implementation vs. ADT ImplementationADT

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

20.  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

21.  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

22.  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

23.  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

24.  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

25.  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

26.  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

27. 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

28.  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

29.  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

30. 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

31. Using Stack

33. Your Turn  Get into your groups and complete activity

34. 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