Variables
I understand why you have the Range.this.end and Range.this.start to avoid confusion about where those variables come from... If you need the Range.this as part of the teaching exercise, then sure. Otherwise, I would recommend three things....
- add
rangeas a prefix, even though it is slightly redundant - Make them final...
- one variable per line... (it makes revision-control diffs/patches easier to read)
The code would look like:
private final int rangeStart;
private final int rangeEnd;
Then, all the Range.this.start would be just rangeStart, etc.
Nested classes
Your iterator class is a non-static class, so it can reference the outer class's range start/end.
In this case, the nested class can be changed to a static class very easily. This has the potential of simplifying memory management because the iterator does not need a reference to the enclosing Range.
Consider a private-static Iterator instance:
// Inner class example
private static final class RangeIterator implements
Iterator<Integer> {
private int cursor;
private final int end;
public RangeIterator(int start, int end) {
this.cursor = start;
this.end = end;
}
public boolean hasNext() {
return this.cursor < end;
}
public Integer next() {
if(this.hasNext()) {
int current = cursor;
cursor ++;
return current;
}
throw new NoSuchElementException();
}
public void remove() {
throw new UnsupportedOperationException();
}
}
This static class removes the need for the back-references to Range.this entirely....
The new iterator is called simply with:
public Iterator<Integer> iterator() {
return new RangeIterator(start, end);
}
Pre-Validate
It is better to pre-validate state, than to fall-through to an error... This code:
public Integer next() { if(this.hasNext()) { int current = cursor; cursor ++; return current; } throw new NoSuchElementException(); }
would be better as:
public Integer next() {
if(!this.hasNext()) {
throw new NoSuchElementException();
}
int current = cursor;
cursor ++;
return current;
}
Post-Increment
This block can be simplified:
int current = cursor; cursor ++; return current;
to just:
return cursor++;
although I imagine this is done as an education ploy.
Integer as the example
Because of the int autoboxing I worry that Integer may not be the right choice for data type. You may want to consider a non-primitive as the data.
Autoboxing is the sort of thing that will confuse.
Conclusion
Otherwise, I don't see much in the way of problems.
Overall, it's pretty good code to learn from.
Functionality
I like that you've used the inclusive-exclusive convention for the lower and upper bounds, respectively. The rationale for that design would be an interesting discussion topic.
I suggest adding a second constructor for convenience:
public Range(int end) {
this(0, end);
}
There should probably be getters for start() and end(). Technically, you should override .equals() and .hashCode() as well, but maybe it's OK to leave them out for simplicity.
Style
As @rpg711 noted, putting the @Override annotation everywhere would be good practice. It would also help students see which methods are mandatory parts of the interface (well, practically all of them).
JavaDoc would be a good habit to teach. At the least, document the outer class and inner class, and probably their constructors as well.
It would be more conventional to put a space after the if, for, and while keywords. They look less like function calls that way.
Declaring start and end as final could help emphasize to students that the Range is immutable, and only the RangeIterator changes state. Perhaps adding final would alleviate some of @rolfl's concerns about the inner class referring to Range.this.start and Range.this.end.
In agreement with @rolfl, I would also personally prefer
@Override
public Integer next() {
if (!this.hasNext()) {
throw new NoSuchElementException();
}
// The post-increment magically takes effect _after_
// returning. This is equivalent to
//
// int value = this.cursor++;
// return value;
//
return this.cursor++;
}
… though I can understand if you choose not to burden the students with that trivia.
Test case
It would be useful to illustrate that two RangeIterators keep state independently. Perhaps this might make a good example?
Range digits = new Range(0, 10);
for (Integer tensDigit : digits) {
for (Integer onesDigit : digits) {
System.out.format("%s%s ", tensDigit, onesDigit);
}
System.out.println();
}