作者AmosYang (Zzz...)
看板Translate-CS
標題Re: [翻譯] Java Collection API 的怪事
時間Fri Mar 22 17:16:20 2013
※ 引述《PsMonkey (痞子軍團團長)》之銘言：
: 重點在於，`UnmodifiableCollection` 並沒有實作 `hashCode()` 跟 `equals()`，
: 所以當你要一個 `UnmodifiableCollection` 作 `hashCode()` 時，
: 會直接使用 `Object` 的 `hashCode()`。
這個題目很有意思
與其說 UnmodifiableCollection 沒有實作 hashCode 與 equals
更精確的說法是: UnmodifiableCollection 沒辦法有意義地實作 hashCode 與 equals
原因在於 delegate pattern: UnmondifiableCollection 與其原本的 Collection
之間是 has-a 而非 is-a 的關係
原文裡舉了以下這個例子
List L = { /* a list of things */ }
Collection C1 = L.unmodifiableCollection();
Collection C2 = L.unmodifiableList();
bool B1 = C1.equals(C2);
bool B2 = C2.equals(C1);
這時候
1. 在 Java 裡, B1 與 B2 必須有一樣的結果
2. List.equals(x) 規定, 如果 x 不是 List, 那就不能傳回 true
3. C2 是個 List
4. C1 只是個 Collection
因為 #2, 3, 4, 所以 B2 必須傳回 false -- #5
因為 #1 與 #5, B1 也必須是 false -- #6
至此，讀者可以試試看去實作 UnmodifiableCollection.equals()
就會發現，要嘛就是無法正確處理上述這類案例，要嘛最後總是傳回 false
是故，乾脆放棄實作 equals() 的打算; 易言之，不是不為，而是不能為矣
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 98.26.14.35
※ 編輯: AmosYang 來自: 98.26.14.35 (03/22 17:21)
※ 編輯: AmosYang 來自: 98.26.14.35 (03/22 17:28)
※ 編輯: AmosYang 來自: 98.26.14.35 (03/22 17:31)