Re: [翻譯] Java Collection API 的怪事

看板Translate-CS作者 (Zzz...)時間11年前 (2013/03/22 17:16), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串5/5 (看更多)
※ 引述《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)
文章代碼(AID): #1HJ25caC (Translate-CS)
文章代碼(AID): #1HJ25caC (Translate-CS)