Why does Scanner implement Iterator?

问题:

I was just wondering why java.util.Scanner implements java.util.Iterator?

Scanner implements the remove method and throws an UnsupportedOperationException.

But shouldn't a class, when implementing an interface, fulfill the contract of the interface?

What is the use of implementing iterator and adding a method that throws an exception?

Why not just avoid the implementation of the interface and keep it simple?

One can argue that it is defined so that the class which might extend Scanner could implement the method, like AbstractList has an add method that throws an UnsupportedOperationException. But AbstractList is an abstract class, whereas Scanner is a final class.

Is this not a bad design practice?

回答1:

I'd say yes, it's a design flaw. The flaw is within Iterator. This issue could be thrown in the same category as attempting to create an immutable Collection implementation.

It violates the Interface Segregation Principle and forces the developers to include a corner case into the JavaDocs (the infamous UnsupportedOperationException) to avoid violating the Liskov Subsitution Principle. You'll find this in Collection#remove methods aswell.

---

I believe design could be improved by decomposing the interface, segregating hasNext() and next() into a new (immutable) interface and letting the (mutable) Iterator interface derive from it :

interface Traversable<E> {
    boolean hasNext();
    E next();
}

interface Iterator<E> extends Traversable<E> {
    void remove();
}

final class Scanner implements Traversable<String> {

}

Better names could definitely be used. Please don't down this post due to my bad naming choices.

Why does Scanner implement Iterator in the first place?

Scanner is not an iterator in the sense of traversing a collection. But the idea of a Scanner is to supply it input to be "scanned", which in a sense is iterating over something (the characters in a String).

I can see why Scanner would implement Iterator (you were asking for a use case). For example, if you wanted to create your own Iterable type to iterate over a String specifying a delimiter:

class ScannerWrapper implements Iterable<E> {
    public Scanner scanner;

    public ScannerWrapper(Scanner scanner) {
        this.scanner = scanner;
    }

    public Iterator<String> iterator() {
        return scanner;
    }
} 

Scanner scanner = new Scanner("one,two,three");
scanner.useDelimiter(",");
ScannerWrapper wrapper = new ScannerWrapper(scanner);

for(String s : wrapper) {
    System.out.println(s);
}

But this would have also worked if the JDK supported a Traversable type and allowed enhanced loops to accept Traversable items, since removing from a collection in this fashion may throw a ConcurrentModificationException, which leads to using an iterator instead.

Conclusion

So is it good design? Nope. It violates ISP and results in cluttered contracts. This is simply a giagantic code smell. The real problem is the language's lack of support for immutability, which should allow developers to specify whether a behavior should mutate state, allowing behavioral contracts to be stripped of their mutability. Or something along those lines..

The JDK is filled with stuff like this (bad design choices, such as exposing length for arrays and attempts at an ImmutableMap I mentioned above), and changing it now would result in breaking code.

回答2:

Because implementing iterator allows the scanner to be used wherever a read only iterator can be used.

Furthermore it does implement the contract. From the Iterator documentation (emphasis mine):

remove() Removes from the underlying collection the last element returned by this iterator (optional operation).

回答3:

It's just not a supported method. To avoid implementing it that way would require a similar interface without a remove method. Is it good design to create multiple similar interfaces just to avoid a method that throws NotImplementedException?

Anyone using a Scanner knows (or will soon know) that the remove() method can't be used, so it really has no practical effect. It could also be a no-op, since effectively the item is removed, just not due to remove(), but it's probably clearer to throw an exception.

回答4:

For an official answer, see the Collections Framework Overview. Scroll down to the bottom for Design Goals.

To keep the number of core interfaces small, the interfaces do not attempt to capture such subtle distinctions as mutability, modifiability, and resizability. Instead, certain calls in the core interfaces are optional, enabling implementations to throw an UnsupportedOperationException to indicate that they do not support a specified optional operation. Collection implementers must clearly document which optional operations are supported by an implementation.

As previous answers have pointed out, the Collections framework could uphold Liskov Substition by decomposing its interfaces into numerous, smaller interfaces. That approach was considered and rejected, in order to minimize the number of core interfaces in the framework.