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, that is, which item (if any) should be returned next, and which item (if any) should be removed
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 at least one variable to keep track of where it is in the traversal, that is, which elements have not yet been returned
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 that 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
```

In-class exercise

work with your friends

add an iterator method to this ArrayList class:

public class ArrayList<E> {
  protected E [] data;
  protected int size;
   /* implementation of the ArrayList methods */

you do this by first defining an ArrayListIterator class:

public class ArrayListIterator<E> implements Iterator<E> {
   /* you should declare some class variables */
   /* you should declare some constructor(s) */
   public boolean has_next () {
     /* your code goes here */
   }
   public E next () {
     /* your code goes here */
   }
   public void remove () {
     throw new UnsupportedOperationException ("not supported");
   }
}

then, implement the iterator method:
```
   Iterator<E> iterator() {  // create and return an iterator
      /* your code goes here */
   }
```
The iterator method is implemented inside the ArrayList class, and returns an object of type ArrayListIterator

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<String> values = ...

for (String value: values) {
  System.out.println ("next string is " + 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