扫描仪为什么实现迭代器？

Question

我只是想知道为什么是java。util。扫描器实现java。util。迭代器？

Scanner实现删除方法，并抛出一个不支持的操作异常。

但是一个类在实现接口时，不应该履行接口的契约吗？

实现迭代器并添加引发异常的方法有什么用？

为什么不直接避免接口的实现并保持简单呢？

有人可能会争辩说，它的定义是为了让可能扩展Scanner的类能够实现该方法，就像AbstractList有一个add方法抛出一个UnsupportedOperationException。但是AbstractList是一个abstract类，而Scanner是一个final类。

这不是一个糟糕的设计实践吗？




Answer 1

有关官方答案，请参阅集合框架概述。向下滚动至底部以查看设计目标。

为了保持核心接口的数量较小，这些接口不试图捕捉诸如可变性、可修改性和可调整性等细微差别。相反，核心接口中的某些调用是可选的，使实现能够抛出UnsupportedOperationException，以指示它们不支持指定的可选操作。集合实现者必须清楚地记录实现支持哪些可选操作。

正如前面的答案所指出的那样，集合框架可以通过将其接口分解为许多更小的接口来支持Liskov substation。为了尽量减少框架中核心接口的数量，考虑并拒绝了这种方法。

Answer 2

因为实现迭代器允许在任何可以使用只读迭代器的地方使用扫描器。

此外，它确实执行了合同。从迭代器文档（我的重点）：

remove（）从基础集合中移除此迭代器返回的最后一个元素（可选操作）。

Answer 3

我会说是的，这是一个设计缺陷。该漏洞位于迭代器中。此问题可能与试图创建不可变的集合实现的问题属于同一类别。

它违反了接口隔离原则，并迫使开发人员在JavaDocs中包含一个角落大小写（臭名昭著的Unsupport tedoperationExc0019），以避免违反Liskov Subsittion原则。您可以在集合#移除方法中找到这一点。

我相信设计可以通过分解接口来改进，将hasNext（）和Next（）分离到一个新的（不可变的）接口中，并让（可变的）Iterator接口从中派生：

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

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

final class Scanner implements Traversable<String> {

}

当然可以用更好的名字。请不要因为我糟糕的命名选择而写下这篇文章。

Scanner不是遍历集合的迭代器。但是扫描器的想法是为它提供“扫描”的输入，从某种意义上说，这是对某些东西（字符串中的字符）的迭代。

我可以理解为什么Scanner将实现Iterator（您要求使用用例）。例如，如果您想创建自己的Iterable类型来迭代指定分隔符的String：

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);
}

但是，如果JDK支持Traversable类型并允许增强的循环接受Traversable项，这也会起作用，因为以这种方式从集合中删除可能会抛出一个ConnettModificationExc0019，这导致使用迭代器相反。

那么这是一个好的设计吗？不。它违反了ISP，导致合同混乱。这只是一种巨大的代码味道。真正的问题是该语言缺乏对不变性的支持，这应该允许开发人员指定行为是否应该改变状态，从而使行为契约不再具有可变性。或者类似的东西。。

JDK中充满了这样的东西（糟糕的设计选择，比如为数组暴露length，尝试ImmutableMap），现在更改它会导致代码中断。