為什么 AbstractCollection 不實現 size()？

Question

當對AbstractCollection進行子類化時，我仍然必須實現size() ，即使（我相信）有一個合理的正確（雖然不是性能）默認實現：

public int size() {
    int count = 0;

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

    return count;
}

為什么設計者沒有包含size()的默認實現？ 他們是否試圖強迫開發人員有意識地考慮這種方法，希望讓開發人員提供一個性能比默認更好的實現？

Answer 1

我懷疑你的最后一句話是真正的原因。 當子類化抽象 class 時，有時只覆蓋抽象方法很誘人。 我希望幾乎每個實現都有一個比迭代更好的實現——所以如果你希望幾乎每個人都覆蓋一個方法，那么不提供基本（慢）實現可能是個好主意。 它只是減少了搞砸的機會:)

Answer 2

雖然這是一種可能的默認實現，但它不一定是好的（甚至是理智的）。

在幾乎所有通用的Collection實現中，都有一個 O(1) 的方法來找出大小。 通常通過簡單地查詢一個簡單的字段。

這應該是實現。 在極少數情況並非如此的情況下，實現仍可能回退到您的示例代碼（或以不同方式實現）。

Answer 3

我支持你的理論：也許實現者只是被迫為size()實現一個好的（如果可能的話O(1) ）實現，因為

• 該方法經常使用
• 如果我們針對接口編程，我們不知道實際的集合類型
• 默認（或錯誤）實現可能會意外降低性能

Answer 4

對於某些類型的列表，您建議的默認實現是有害的。 我正在考慮惰性列表，或者迭代時會導致非常大的內存數據結構的列表。

在無限惰性列表的情況下，您建議的默認實現顯然是不正確的。

Answer 5

實際上，由於add和remove操作都有一個返回值，表明該操作是否導致集合大小的變化，所以在大多數情況下，您可以通過跟蹤 add 和 remove 來實現事件更好的size方法。