Somehow I seem to be fascinated by an Iterator ;-)
So I decided to google for it and these were the phrases I gathered from the web
- is an extremely powerful interface for accessing items from a collection one item at a time.
- it is a looping construct where you don't need to know the data structure in order to loop over it.
- it is separate from the collection itself (side benefit - allows more than 1 iterator to exist at a time !!)
humm ... What the heck. I already knew all this. Decided that I needed another approach to know it better.
So fired up my trusty IntelliJ IDE and decided to make my own iterator for my own collection object.
I decided that "MyContainer" would somehow return a "MyContainerIterator" when I asked for an iterator. MyContainer would implement the collection using an ArrayList internally. MyContainerIterator would implement the Iterator interface.
This was my Test Class
// job: Understands how myContainer and myContainerIterator work and verifies it
public class IteratorTest extends TestCase {
private MyContainer myContainer;
protected void setUp() throws Exception {
myContainer = new MyContainer();
myContainer.add("Hello");
}
public void testCreateIteratorReturnsAnIterator() {
assertNotNull(myContainer.iterator());
}
public void testAddingToMyContainer() {
assertEquals("Hello", myContainer.get(0));
}
public void testIteratorWorksWithMultipleAdditions() {
Iterator iterator = myContainer.iterator();
assertEquals("Hello", iterator.next());
myContainer.add("Yo");
assertEquals("Yo", iterator.next());
}
}
My Collection class
// Job: Understands a collection
public class MyContainer {
private List storage = new ArrayList();
public void add(Object s) {
storage.add(s);
}
public Object get(int i) {
return storage.get(i);
}
Iterator iterator() {
return new MyContainerIterator(storage);
}
}
My Iterator
//job: Understands how to traverse over a MyContainer Collection
public class MyContainerIterator implements Iterator {
private List storage;
int index;
public MyContainerIterator(List storage) {
this.storage = storage;
}
public boolean hasNext() {
return index < storage.size();
}
public Object next() {
return storage.get(index++);
}
public void remove() {
}
}
That was a pretty interesting exercise.
------------------
a small modification
I just showed this piece of code to Suresh and we talked about quite a few modifications to this code. This was one of them
// Job: Understands a collection
public class MyContainer {
private List storage = new ArrayList();
public void add(Object s) {
storage.add(s);
}
public Object get(int i) {
return storage.get(i);
}
Iterator iterator() {
return new MyContainerIterator(storage);
}
//job: Understands how to traverse over a MyContainer Collection
private class MyContainerIterator implements Iterator {
private List storage;
int index;
public MyContainerIterator(List storage) {
this.storage = storage;
}
public boolean hasNext() {
return index < storage.size();
}
public Object next() {
return storage.get(index++);
}
public void remove() {
}
}
}
By Making the Iterator an Inner Class of the collection itself, we felt it exhibhited better encapsulation as this iterator implementation can be optimised for the type of Collection that it supports and just expose an Iterator interface.
The other things that we spoke about mainly revolved around the inefficieny of this whole thing. But then I wrote it to see how iterators worked.
But another interesting case of how pair programming would have worked, had Suresh and myself paired on this exercise. This design would have come out much earlier instead of the code review kind of session after the code was written.
