Outline

• iterator review
• iterator implementation
• the Java foreach statement
• testing

Looping over the elements of a collection

• looping over the elements of a linked list with get:

    for (int i = 0; i < List.size(); i++) {
      E element = List.get(i);
      ... // do something with element
    }
  

  if get is O(n), the loop takes O(n²) time
• an iterator can be more efficient and simpler:

    Iterator<E> iter = List.iterator();
    while (iter.hasNext()) {
      E element = iter.next();
      ... // do something with element
    }
  

  if iter.next is O(1), the loop takes O(n) time

Java Iterators

• the iterator encapsulates the state of the list traversal
• using the ideas of an ADT, the attributes of the iterator are its current position in the traversal, and the behaviors of the iterator are the three methods hasNext, next, and (optionally) remove.

Iterator Implementation

• a Java iterator may or may not be internal to the collection class
• every Java iterator must have sequential access to the elements of the collection
• every Java iterator must have at least one variable to keep track of where it is in the traversal, that is, which elements have not yet been returned
• the iterator could make a copy of the entire collection, but that is unusual
• See LinkedListIterator.java for a very simple iterator on linked lists.
• in-class exercise (everyone together): design the code for the iterator() method of the LinkedList class
• any class that provides an iterator() method the returns a valid iterator, satisfies the Iterable interface, which simply requires an iterator method:

  Iterator<E> iterator();  // create and return an iterator for this collection
  

Java for/foreach

• instead of having to use the while loop to use an iterator, the for loop has been specialized to repeatedly call the iterator for any Iterable class:

  LinkedList<Integer> values = ...
  
  int sum = 0;
  for (Integer value: values) {
    sum = sum + value;
  }
  

• Java creates an iterator by calling values.iterator(), and calls the methods (hasNext() and next()) of this iterator, but the iterator itself is not visible in the code
• this way of using the for statement is called a for each or foreach statement, and is also known as the Java enhanced for statement
• foreach can also be used with arrays:

  int [] values = ...
  
  int sum = 0;
  for (int value: values) {
    sum = sum + value;
  }
  

• the foreach statement works on any expression that has a value that satisfies the Iterable interface

Testing

• unless the code is written correctly from the start, the errors must be found by testing the code
• writing correct code is a lot of work, so most programmers use testing to make their code as close to correct as possible
• test routines can (and probably should) be included in the main method of any class that doesn't already have one. This is a unit test. This main method is a driver program. The driver program can also be defined separately.
• the unit test should call all the methods of the class, with as many combinations of parameters as possible
• if the writer of the test code doesn't study the code under test, this is black box testing
• at the very least, the goal of testing is full coverage: making sure that every path through the code has been used at least once, and has produced an acceptable result
• to produce full coverage, the programmer of the test program must study the code being tested: this is white box testing

A few common types of errors

• off-by-one (fencepost): how many fence posts are needed for a fence that is 20 feet long and has a post every 2 feet?
• not initializing data correctly. Sometimes this causes null pointer access
• using different variables as if they were one, or using one variable as if it were two variables
• assumptions that don't turn out to be true (misconceptions), not establishing and maintaining invariants
• not checking things that should be checked, e.g. if (x == null)

testing strategies

• print/show all method invocations and their parameters and return values
• write code to check that the invariants are established and maintained
• write test cases to not only provide full coverage, but also check all boundary conditions, where the result should change (make sure it changes where it should)
• some common special cases:
  • < 0, 0, 1, > 1
  • first and last elements of an array, collection, linked list
  • elements and values that are null
  • desired element is not in the collection, or is in the collection more than once
  • collection has size 0, 1, or larger
• for example, when testing inserting on a linked list, can test inserting at the beginning of a linked list, at the end, in the middle, and inserting into an empty linked list. Also, inserting an element that has the value null (is the behavior of your program defined in that case? Should it be?)
• if code to be tested needs to call a method that is not yet implemented, a stub of that method can do only what is needed for the test

reasoning about programs

• a precondition must be true before a method is called
• the code in the method may (and usually will) assume that the precondition is true
• the caller of a method must guarantee (be sure) that the precondition holds
• a postcondition will be true after a method is called
• the code in the method must guarantee that the postcondition is true
• preconditions and postconditions are a little bit like a contract or any other agreement: if the caller provides the preconditions, the method will provide the postconditions
• preconditions and postconditions are documented in Javadoc
• invariants are postconditions of every method, including the constructors
• invariants are preconditions of every method except the constructors
• invariants are usually documented for the entire class rather than for each method