原文網址：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)