java - 为什么他们决定让接口(interface)有 "Optional Operations"

Question

ImmutableSet实现 Set界面。对 ImmutableSet 没有意义的函数现在称为 Set 的“可选操作”。我假设是这样的情况。所以 ImmutableSet 现在会为许多可选操作抛出 UnsupportedOperationException。

这对我来说似乎倒退了。有人告诉我，接口(interface)是一种契约，因此您可以在不同的实现中使用强加功能。可选操作的方法似乎从根本上改变了(矛盾？)接口(interface)的用途。今天要实现这个，我会将 Set 接口(interface)分成两个接口(interface):一个用于不可变操作，另一个用于扩展这些操作以用于修改器。 (非常快，现成的解决方案)

我了解技术在不断变化。我不是说它应该以某种方式完成。我的问题是，这种变化是否反射(reflect)了 Java 某些基本理念的变化？使事情向后兼容只是一个创可贴吗？我对接口(interface)的理解不完整吗？

Answer 1

Java Collections API Design FAQ详细回答这个问题:

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

A: 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.

简而言之，拥有像 Set 这样带有可选操作的接口(interface)是为了防止所需的不同接口(interface)数量呈指数级增长。它不仅仅是“不可变”和“可变”那么简单。 Guava 的 ImmutableSet 然后必须实现 Set 才能与所有其他使用 Set 的代码互操作。这并不理想，但确实没有更好的方法。