Question

在对AbstractCollection进行子类化时，我仍然必须实现size()，即使（我相信）有一个~~合理的~~正确（尽管是非高效的）默认实现：

public int size() {
    int count = 0;

    for (Iterator<E> i = iterator(); i.hasNext();) {
        i.next();
        count++
    }

    return count;
}

为什么设计师不包含size()的默认实现？他们是否试图强迫开发人员有意识地考虑这种方法，希望开发人员能够提供性能优于默认值的实现？

Answer 1

我怀疑你的最后一句是真正的原因。在对抽象类进行子类化时，有时候只能覆盖抽象方法。我希望几乎每个实现都有一个比迭代更好的实现 - 所以如果你想要几乎每个人都要覆盖一个方法，那么不提供一个方法可能是个好主意。基础（慢）实施。它只是减少搞砸的机会：）

Answer 2

虽然这是可能的默认实现，但它不一定是好的（甚至是理智的）。

在几乎所有通用Collection实现中，有一种O（1）方法可以找出大小。通常只需查询一个简单的字段。

这应该是实施。在极少数情况下，情况并非如此，实现仍然可以回溯到您的示例代码（或以不同方式实现）。

Answer 3

我支持你的理论：也许实施者只是被迫为O(1)实现一个好的（size()）实现，因为

该方法经常使用
如果我们针对接口进行编程，我们不知道实际的集合类型
默认（或不良）实施可能会意外中断性能

Answer 4

对于某些类型的列表，您建议的默认实施是有害的。我正在考虑延迟列表，或者在迭代时导致内存数据结构非常庞大的列表。

在无限延迟列表的情况下，您建议的默认实现明显不正确。

Answer 5

实际上，由于add和remove操作都有一个返回值，指示操作是否导致更改了集合的大小，因此可以更好地实现事件{{1}通过跟踪大多数情况下的添加和删除方法。

为什么AbstractCollection没有实现size（）？

5 个答案: