他們爲什麼決定讓接口具有「可選操作」

Question

ImmutableSet實現了Set接口。對ImmutableSet無意義的功能現在稱爲Set的「可選操作」。我假設這樣的情況。因此ImmutableSet現在爲許多可選操作拋出了UnsupportedOperationException。

這似乎倒退給我。我被告知Interface是一個合約，以便您可以在不同的實現中使用強加功能。可選操作的方法似乎從根本上改變（矛盾？）接口意味着要做什麼。今天實現這個，我會將Set接口分成兩個接口：一個接口用於不可變操作，另一個接口擴展這些mutators操作。 （非常快，關閉袖口解決方案）

我知道技術的變化。我不是說應該這樣或那樣的。我的問題是，這種變化是否反映了Java的某些基礎哲學的變化？它只是更多的東西，使事情向後兼容？我對接口有不完全的理解嗎？

Answer 1

的Java Collections API Design FAQ回答這個問題詳細：

問：你爲什麼不直接支持不可改變的核心集合接口，讓您可以與可選的操作（和UnsupportedOperationException異常）做了嗎？

答：這是整個API中最具爭議性的設計決策。顯然，靜態（編譯時）類型檢查是非常可取的，並且是Java中的常態。如果我們相信這是可行的，我們會支持它。不幸的是，試圖實現這個目標會導致接口層次的大小激增，並且不能成功地消除對運行時異常的需要（儘管它們大大減少了它）。

Doug Lea編寫了一個廣受歡迎的Java集合包，它的界面層次體現了可變性的區別，他不再相信這是一個可行的方法，基於用戶體驗他的集合包。用他的話來說（來自個人信件）「很多人說我很痛苦，強大的靜態類型不適用於Java中的集合接口。」

爲了說明血腥細節中的問題，假設您想要將可修改性的概念添加到層次結構中。您需要四個新的接口：ModifiableCollection，ModifiableSet，ModifiableList和ModifiableMap。以前簡單的層次結構現在是一個混亂的層次結構。此外，您還需要一個新的Iterator接口，以便與不可修改的集合一起使用，該接口不包含刪除操作。現在你可以拋棄UnsupportedOperationException了嗎？不幸的是，考慮數組。考慮數組。他們實施大部分列表操作，但不能刪除和添加。他們是「固定大小」列表。如果要在層次結構中捕獲這個概念，則必須添加兩個新接口：VariableSizeList和VariableSizeMap。您不必添加VariableSizeCollection和VariableSizeSet，因爲它們與ModifiableCollection和ModifiableSet相同，但爲了一致性，您可以選擇添加它們。此外，您還需要一種不支持添加和刪除操作的新ListIterator，以配合不可修改的List。現在我們有多達十個或十二個接口，再加上兩個新的Iterator接口，而不是我們原來的四個接口。我們完了嗎？考慮日誌（例如錯誤日誌，可恢復數據對象的審計日誌和日誌）。它們是自然附加序列，除了刪除和設置（替換）以外，它們都支持所有的列表操作。他們需要一個新的核心接口和一個新的迭代器。

那麼不可變的集合，而不是不可修改的集合呢？ （即客戶不能更改的集合，並且由於任何其他原因決不會改變）。許多人認爲這是最重要的區別，因爲它允許多個線程同時訪問集合而不需要同步。將此支持添加到類型層次結構中需要四個接口。

現在我們可以使用二十個左右的接口和五個迭代器，而且幾乎可以肯定的是，在實踐中仍然存在一些集合，這些集合並不能完全適合任何接口。例如，Map返回的collection-views是自然的只刪除集合。另外，有些集合會根據它們的值拒絕某些元素，所以我們仍然沒有廢除運行時異常。

當所有的事情都說完之後，我們覺得通過提供一小組可以拋出運行時異常的核心接口來回避整個問題是一種合理的工程折衷。

總之，具有類似於Set可選操作界面做是爲了防止在需要不同接口的數量呈指數爆炸。它不像「不可變」和「可變」那麼簡單。然後，Guava的ImmutableSet必須實現Set以與所有其他使用Set的代碼進行互操作。這並不理想，但實際上沒有更好的辦法。