InterfaceIterator

Extra practice. The lesson on the interface the official list does name is Implementing Comparable.

The official topic list names one interface and no other: Implementing an interface, such as Comparable. An iterator is not on that list. Work it once you are sure of Comparable, because writing one is the same skill on a harder promise, and because the practice exam includes one.

You write 2 short methods inside a nested class. Everything else in the file is already written. You check them by running the provided Tester and holding what your program prints against the expected output, line for line.

This device is not saving progress, so your checks will be gone when you reload.

What the two methods must do

MyList keeps its values in an ArrayList<String>. It is declared implements Iterable, which is a promise that you can walk it with the enhanced for loop. That promise is only kept if something can hand out a cursor and step it one value at a time. The cursor is the nested class MyListIterator. It is written for you except for the two methods that make it move.

• hasNext answers one question. Is there still a value left to hand out? It returns true or false and it changes nothing, so calling it repeatedly gives the same answer every time.
• next hands back the value the cursor is sitting on, and then moves the cursor forward one place, so the following call gives the value after it.

Both signatures are already in the file. Do not change them.

public boolean hasNext()

public Object next()

next returns Object, not String. The class is written against the raw Iterator type, so Object is the declared return. Leave it that way. Your compiler may print a warning about raw types. A warning is not an error and it costs you nothing.

What is already written for you

• private ArrayList<String> list; on MyList holds the values. addLast puts each one on the end, so they come out in the order they went in.
• public Iterator iterator() returns new MyListIterator(0, this.list). A brand new cursor, starting at position 0, every single time it is called.
• The nested public class MyListIterator implements Iterator has two fields, private int cur and private ArrayList<String> listRef, and a constructor that sets both from what it was passed.
• remove() already throws UnsupportedOperationException with the message remove not implemented for MyListIterator. It is not yours to write and not yours to change.
• toString() on MyList builds its result with an enhanced for loop over itself, so it depends on your two methods as well.

The shape of the answer

hasNext is one comparison

The values sit at positions 0 through listRef.size() - 1. cur holds the position of the value that has not been handed out yet. So there is still something left exactly when cur is inside the list, and that is a comparison between cur and listRef.size(), strictly less than. Return the comparison. You can wrap it in an if that returns true or false, and it is not wrong, but it is more to get right under time pressure.

Two things hasNext must not do. It must not move cur, or the loop skips every other value. It must not ask listRef for a value in order to find out whether one is there, because asking for a position that does not exist is what hasNext exists to prevent.

next is three moves, in this order

1. Read. Get the value at position cur out of listRef and hold it in a local variable.
2. Move. Add one to cur.
3. Return. Give back the value you held, not a fresh read after the move.

The order is the whole method. Move first and you hand back the wrong value and run off the end on the last call. A local variable inside your own method body is fine. The rule about not changing variables covers the fields and the signatures you were given, not a temporary you declare inside your own method.

Trace it once

The list holds apple, banana, cherry, so listRef.size() is 3 and a fresh cursor starts at cur 0.

Read two things off that table. cur ends at size, not at size - 1, and that is correct. And hasNext is the only thing stopping the walk, which is why its comparison carries the safety of the whole method.

The enhanced for loop is that same walk

This line:

for (Object o : list)
   System.out.println(o);

is compiled into this:

Iterator it = list.iterator();
while (it.hasNext())
   System.out.println(it.next());

Nothing else happens. So the symptoms map straight back to your code. A for-each loop that prints nothing means hasNext returned false the first time it was asked. A for-each loop that never stops means next is not moving cur. A for-each loop that misses values means something other than next is moving cur.

Notice that the loop starts by calling iterator(), and iterator() builds a new MyListIterator at position 0. That is why the same list can be walked twice.

The cases, one at a time

Tester puts your 2 methods through 5 situations. Every one of them shows up in the output block, so work all 5.

1. Three values, walked with an explicit iterator

Tester gets an iterator into a variable named iter and runs a plain while (iter.hasNext()) loop. This is the straight case. It prints apple, then banana, then cherry. If this one is wrong, all of them are.

2. The same three values, with the enhanced for loop

The explicit walk just left its cursor at the end. The for-each loop still prints all three again, because it calls iterator() and gets its own cursor at 0. Nothing you write resets anything. If you were tempted to make next wrap back around to 0 when it runs out, this is the case that shows why you must not.

3. A list with one value

hasNext is true once, next returns single item, then hasNext is false because cur is 1 and the size is 1. This is the case that separates < from <=. With <= the loop asks for a second value, listRef.get(1) throws IndexOutOfBoundsException, and the program stops there, so everything printed after this point goes missing too.

4. An empty list, with the enhanced for loop

The size is 0 and cur is 0, so hasNext has to be false on the very first ask and the loop body must never run. In the expected output there is nothing at all under that heading. This is where 0 < 0 being false does the work for you, with no special case and no if for the empty list.

5. remove on the used-up iterator

At the end, Tester calls iter.remove() on the iterator from situation 1 and catches the exception. That method is already written and it throws whatever state the cursor is in, so this case comes out right as long as you have not touched it. Leave it alone.

The output you are being compared against

Run Tester and compare every line, blank lines included. Your editor may wrap the run in its own banner lines above and below; those are not part of the comparison.

Using an explicit iterator to walk through list
apple
banana
cherry

Using enhanced for loop to test Iterator
apple
banana
cherry

Testing on a single item list
single item

Testing on MyList object that is empty using enhanced for loop

Unsupported Operation Exception on call to remove.
remove not implemented for MyListIterator

Look at the gap after the empty list heading. That gap is the empty list printing nothing, followed by the blank line that opens the next message. If anything appears in that gap, your hasNext said true on an empty list.

Drill

Four questions. Work each one on paper before you tap.

public boolean hasNext()
{
   return this.cur <= this.listRef.size();
}

public Object next()
{
   this.cur++;
   return this.listRef.get(this.cur);
}

public Object next()
{
   return this.listRef.get(this.cur);
}

Write it out

These two are not scored. Type them from memory into the box, then open the check and hold your version against it. The box is scratch space and is not saved.

Your checklist

Tick these when they are true.

• I can say in one sentence each what hasNext promises and what next promises.
• My hasNext compares cur with listRef.size() using strictly less than, and it changes nothing.
• My next reads at cur, then moves cur, then returns the value it saved, in that order.
• I traced the empty list and the one value list by hand, and both stop at the right moment.
• I can explain why the for-each loop after the explicit walk prints all three values again.
• I ran Tester and every line matched the expected output, blank lines included.

Could you write this cold?

Not "did I follow along". Blank file, no notes, 4 hours on a clock, and no way to look anything up. Say yes only when that is true. You can take it back at any time.

If a piece of this is shaky

• An Interface Is a Promise a Type Makes
• Walking a List with a Cursor
• The Empty List Is Already Handled
• Declaring a Class Inside Another Class
• Implementing Comparable, the interface the official list names
• Data abstraction and class design