java - 集合层次结构应该是 Collection (Read Only) -> ModulatedCollection

Question

当前的java框架提供了一个Collection类，然后提供了一种从集合中获取“不可修改”集合的方法。不存在与公开暴露的不可修改集合相对应的类。如果我要重新设计一个 Collection 类层次结构，我将拥有一个 Collection 接口(interface)(只读)，其中包含 ModABLECollection 的子类(这是可以修改的)。当前的方法是不够的，因为它只提供运行时错误检查而不是编译时检查。使用位于层次结构底部的显式只读集合类，可以避免运行时错误。

请注意，我在这里指的是只读集合，而不是不可变的，尽管概念相似。请参阅https://stackoverflow.com/a/27611460/4350148 。

提出这个问题的部分原因是我在编写代码时遇到的问题。我发现有时我会在已经不可修改的集合上调用 Collections.unmodifyingCollection(Collection col) 。该方法只是再次包装集合。使用只读版本，每个方法都会更清楚，返回哪种类型的集合，以及方法是否可以更改其集合类型参数之一的内容。

这种方法更有意义吗？或者我在这里遗漏了什么？

Answer 1

这被考虑并拒绝了，因为它会导致集合层次结构中出现太多的接口(interface)和类:

Why don't you support immutability directly in the core collection interfaces so that you can do away with optional operations (and UnsupportedOperationException)?

This is the most controversial design decision in the whole API. Clearly, static (compile time) type checking is highly desirable, and is the norm in Java. We would have supported it if we believed it were feasible. Unfortunately, attempts to achieve this goal cause an explosion in the size of the interface hierarchy, and do not succeed in eliminating the need for runtime exceptions (though they reduce it substantially).

Doug Lea, who wrote a popular Java collections package that did reflect mutability distinctions in its interface hierarchy, no longer believes it is a viable approach, based on user experience with his collections package. In his words (from personal correspondence) "Much as it pains me to say it, strong static typing does not work for collection interfaces in Java."

To illustrate the problem in gory detail, suppose you want to add the notion of modifiability to the Hierarchy. You need four new interfaces: ModifiableCollection, ModifiableSet, ModifiableList, and ModifiableMap. What was previously a simple hierarchy is now a messy heterarchy. Also, you need a new Iterator interface for use with unmodifiable Collections, that does not contain the remove operation. Now can you do away with UnsupportedOperationException? Unfortunately not.

Consider arrays. They implement most of the List operations, but not remove and add. They are "fixed-size" Lists. If you want to capture this notion in the hierarchy, you have to add two new interfaces: VariableSizeList and VariableSizeMap. You don't have to add VariableSizeCollection and VariableSizeSet, because they'd be identical to ModifiableCollection and ModifiableSet, but you might choose to add them anyway for consistency's sake. Also, you need a new variety of ListIterator that doesn't support the add and remove operations, to go along with unmodifiable List. Now we're up to ten or twelve interfaces, plus two new Iterator interfaces, instead of our original four. Are we done? No.

Consider logs (such as error logs, audit logs and journals for recoverable data objects). They are natural append-only sequences, that support all of the List operations except for remove and set (replace). They require a new core interface, and a new iterator.

And what about immutable Collections, as opposed to unmodifiable ones? (i.e., Collections that cannot be changed by the client AND will never change for any other reason). Many argue that this is the most important distinction of all, because it allows multiple threads to access a collection concurrently without the need for synchronization. Adding this support to the type hierarchy requires four more interfaces.

Now we're up to twenty or so interfaces and five iterators, and it's almost certain that there are still collections arising in practice that don't fit cleanly into any of the interfaces. For example, the collection-views returned by Map are natural delete-only collections. Also, there are collections that will reject certain elements on the basis of their value, so we still haven't done away with runtime exceptions.

When all was said and done, we felt that it was a sound engineering compromise to sidestep the whole issue by providing a very small set of core interfaces that can throw a runtime exception.

( Source )