※ 引述《tkcn (小安)》之铭言： : 其实我对前几天那篇很有兴趣， : 可是不知道为什麽没有後续，文章也不见了 @_@ : 所以我就自己来冒名顶替一下吧。 : // Returns a fixed-size list backed by the specified array. : Arrays.asList(T... a) : 上面这个 method 会回传一个 Arrays$ArrayList 物件， : ArrayList 继承自 AbstractList， : 因为没有 override add() 与 remove()， : 所以一但执行 add() 或 remove()， : 就会丢出 UnsupportedOperationException。 : 看起来一切都合情合理， : 毕竟 Arrays$ArrayList 骨子里是 Array， : 要是能支援 add, remove 那才奇怪的勒 : (java.util.ArrayList 内部虽然也是 Array，但是他始乱终弃) : 让我感到疑惑的是，这样设计的目地到底是什麽? : List 介面明明有提供 add, remove， : 实作他的类别却只会丢出 UnsupportedOperationException， : 这样是一个合理的 OO 设计吗? : 如果不是，那是否有什麽其他的考量呢? 与是不是 array 没关系. 为什麽内部用 array 放就不可以 add remove? 单纯只是那个是一个 unmodifiable list 而已吧. 既然是一个 non-modifiable list, 当然不让你 去增删里面的 elements. 是不是合理的 OO 设计, 这就见仁见智了. 反正 它的 contract 也说明了容许 implementation 不支援某些功能的话, 也不可以说有多错... 或者有人会觉得把 add/remove 放到一个叫 ModifiableList 的 interface, 但我想当初设计上不这样做, 是 多 了这一层的 interface, 用起来就会很麻烦. 反正 90% 情况下用 collection 都是不需要特 定当做 unmodifiable 来使用, class hierarchy 搞得太复杂, 用起来会很混乱, 究竟什麽时候 parameter 要宣告用 modifiable list 什麽时候 要用 (unmodifiable) list 呢? 诸如此类... --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 202.155.236.82