為什么'add'方法在AbstractCollection中不是抽象的？

Question

public abstract class AbstractCollection<E> implements Collection<E> {
    public boolean add(E e) {
        throw new UnsupportedOperationException();
    }

方法add(E e)不是抽象的，而是在擴展抽象類時拋出異常。 遵循這種方法有什么好處？ 如果方法被抽象化，那么它必須強制覆蓋並節省一些混淆。

Answer 1

如果您嘗試修改任何不可修改的集合，則拋出UnsupportedOperationException是標准行為。 例如，它由Collections.unmodifiable包裝器（當前有八個）返回的類的所有變量方法拋出，例如Collections.unmodifiableList ，以及不可變的Collections.emptyList ，以及它們的所有迭代器。

因此， AbstractCollection.add(E)拋出此異常只是為了通過提供有用的默認行為來更容易實現不可修改的集合。 您將看到在所有這些方法中也實現了相同的行為：

• Iterator.remove()
• AbstractList.add(int, E)
• AbstractList.set(int, E)
• AbstractList.remove(int)
• AbstractMap.put(K, V)
• AbstractMap.SimpleImmutableEntry.setValue(V)

（此外，默認情況下會拋出異常，許多方法不會故意拋出異常，而是調用方法，例如AbstractList.clear() ）。

如果方法被抽象化，那么它必須強制覆蓋並節省一些混淆。

也許，但是有很多地方需要不可修改的行為，因此擁有默認實現可能很方便。 它還鼓勵不可修改的集合始終如一地拋出異常; 否則有人可能會通過讓它什么都不做而不是拋出異常來實現一個add方法，這會讓人更加困惑。

當你想要一個可修改的集合時，只需查看你擴展的Abstract*基類的doc，它總是會說明你需要覆蓋哪些其他方法。 例如， AbstractCollection說 ：

要實現不可修改的集合，程序員只需要擴展此類並提供iterator和size方法的實現。 （迭代iterator方法返回的iterator必須實現hasNext和next 。）

要實現可修改的集合，程序員必須另外覆蓋此類的add方法（否則會拋出UnsupportedOperationException ），迭代iterator方法返回的iterator必須另外實現其remove方法。

Answer 2

並非所有集合都是可變的。 此默認實現可以輕松實現不可變集合。

Answer 3

Javadoc中的答案：

如果一個集合因為已經包含該元素的原因而拒絕添加特定元素，那么它必須拋出異常（而不是返回false）。 這保留了在此調用返回后集合始終包含指定元素的不變量。

我們的想法是，如果方法成功執行，您就知道元素在集合中。