[翻譯] Java Collection API 的怪事

看板Translate-CS作者PsMonkey (痞子軍團團長)時間11年前 (2013/03/22 04:31)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串1/5 (看更多)

原文網址：http://www.javacodegeeks.com/2013/03/java-collections-api-quirks.html 譯文網址：http://blog.dontcareabout.us/2013/03/java-collection-api.html 感謝 tkcn 在 Java 技術上的協助。 BBS 版用 markdown 語法撰寫 ______________________________________________________________________ 在提到 Java Collection API 時，我們會認為已經了解全部的東西了，像是 [List]、[Set]、[Map]、[Iterable]、[Iterator]。我們已經準備好 [補強 Java8 的 Collection API][enhance API]。 [List]: http://docs.oracle.com/javase/7/docs/api/java/util/List.html [Set]: http://docs.oracle.com/javase/7/docs/api/java/util/Set.html [Map]: http://docs.oracle.com/javase/7/docs/api/java/util/Map.html [Iterable]: http://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html [Iterator]: http://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html [enhance API]: http://cr.openjdk.java.net/~briangoetz/ lambda/collections-overview.html 但在那之後，每隔一段時間我們就會偶然發現這些奇怪的怪事，來自於 JDK 深處、以及向下相容的遙遠歷史。讓我們來看一下這些不可修改（unmodifiable) 的 collection。不可修改的 collection ------------------- 無論 collection 是否可以修改，都無法跟 collection API 作對應。 JDK 並沒有 immutable 的 `List`、`Set`、`Collection` 的基礎 type，繼承出來的就是 mutable 的 subtype。所以下面這個 API 是不會出現在 JDK 當中的： // Immutable part of the Collection API public interface Collection { boolean contains(Object o); boolean containsAll(Collection<?> c); boolean isEmpty(); int size(); Object[] toArray(); <T> T[] toArray(T[] array); } // Mutable part of the Collection API public interface MutableCollection extends Collection { boolean add(E e); boolean addAll(Collection<? extends E> c); void clear(); boolean remove(Object o); boolean removeAll(Collection<?> c); boolean retainAll(Collection<?> c); } 有幾個可能的原因解釋為甚麼早期 Java 不這樣實作。最可能的原因是：不把 mutable 特性視為一個功能，值得在 type 階層當中佔據一個 type。所以，伴隨而來的 [Collections] 這個 helper class 就會有一些好用的 method，像是 `unmodifiableList()`、`unmodifiableSet()`、 `unmodifiableCollection()`...... 等等。但是在使用不可修改的 collection 時要注意， [JavaDoc 中有一個非常奇怪的事情][quirk in JavaDoc]：回傳的 collection 並沒有原本 collection 的 `hashCode()` 跟 `equals()`，而是使用 `Object` 的 method。當原本的 collection 是 set 或 list 時，就需要 preserve the contract of these operation（譯註：翻譯不能 Orz）。這句話講的相當曖昧不明，它背後的原因是什麼？在 [Stack Overflow] 有一個很棒的解釋：一個 `UnmodifiableList` 是一個 `UnmodifiableCollection`，但是反過來說就不成立了。一個包了 List 的 `UnmodifiableCollection` 並不是一個 `UnmodifiableList`。所以如果你要比較一個包了 foo 這個 `List` 的 `UnmodifiableCollection`、跟包了同樣 `List` foo 的 `UnmodifiableList`，這兩個並不會相等。如果你直接取得被 wrap 的 list，它們就會相等。雖然這個推論是正確的，但是它的影響可能完全在意料之外。 [Collections]: http://docs.oracle.com/javase/7/docs/api/java/util/ Collections.html [quirk in JavaDoc]: http://docs.oracle.com/javase/7/docs/api/java/util/ Collections.html#unmodifiableCollection(java.util.Collection) [Stack Overflow]: http://stackoverflow.com/questions/ 12851229/hashcode-and-equals-for-collections-unmodifiablecollection/ 12851469#12851469 什麼叫底線... ------------- 底線就是你不可以倚賴 `Collections.equals()`。雖然 `List.equals()` 跟 `Set.equals() 有良好定義，但是不要信任 Collection.equals()，它的行為可能沒有意義。當你在 method signature 接了一個 collection 時請記得： public class MyClass { public void doStuff(Collection<?> collection) { // Don't rely on collection.equals() here! } } 譯註 ---- 如果看不懂這篇在幹麼，那容許我畫蛇添足一下。 `Collections.unmodifiableCollection()` 的內容是： return new UnmodifiableCollection<T>(c); 而 `UnmodifiableCollection` 是實作 `Collection`，其實是一個 delegate pattern： static class UnmodifiableCollection<E> implements Collection<E>, Serializable { final Collection<? extends E> c; UnmodifiableCollection(Collection<? extends E> c) { if (c==null) throw new NullPointerException(); this.c = c; } } 重點在於，`UnmodifiableCollection` 並沒有實作 `hashCode()` 跟 `equals()`，所以當你要一個 `UnmodifiableCollection` 作 `hashCode()` 時，會直接使用 `Object` 的 `hashCode()`。 -- 錢鍾書：說出來的話 http://www.psmonkey.org 比不上不說出來的話 Java 版 cookcomic 版只影射著說不出來的話 and more...... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.25.13.90 ※ 編輯: PsMonkey 來自: 114.25.13.90 (03/22 15:59)