java - Java 接口(interface)中的可选方法

Question

据我了解，如果您在 java 中实现接口(interface)，则该接口(interface)中指定的方法必须由实现该接口(interface)的子类使用。

我注意到在某些接口(interface)(例如 Collection 接口(interface))中，有一些方法被注释为可选，但这究竟是什么意思？它让我有点吃惊，因为我认为接口(interface)中指定的所有方法都是必需的？

Answer 1

这里的答案似乎有很多困惑。

Java 语言要求接口(interface)中的每个方法都由该接口(interface)的每个实现来实现。时期。 这条规则没有异常(exception)。说“Collection 是异常(exception)”表明对这里真正发生的事情的理解非常模糊。

重要的是要意识到符合接口(interface)有两个级别:

1. Java 语言可以检查什么。这几乎可以归结为:每种方法都有一些实现吗？

2. 切实履行契约(Contract)。也就是说，实现是否按照接口(interface)中的文档所说的去做？

   编写良好的接口(interface)将包含文档，准确解释实现的预期内容。您的编译器无法为您检查。您需要阅读文档，并按照他们所说的去做。如果你不按照契约(Contract)的规定去做，那么就编译器而言，你将拥有接口(interface)的实现，但这将是一个有缺陷/无效的实现。

在设计 Collections API 时，Joshua Bloch 决定不再使用非常细粒度的接口(interface)来区分集合的不同变体(例如:可读、可写、随机访问等)，而是只使用非常粗略的集合接口(interface)，主要是Collection、List、Set 和 Map，然后将某些操作记录为“可选”。这是为了避免细粒度接口(interface)导致的组合爆炸。来自 Java Collections API Design FAQ :

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.

当 Collections API 中的方法被记录为“可选操作”时，这并不意味着您可以将方法实现留在实现中，也不意味着您可以使用空的方法主体(一方面，其中许多需要返回结果)。相反，这意味着一个有效的实现选择(仍然符合约定)是抛出 UnsupportedOperationException。 .

请注意，由于 UnsupportedOperationException 是一个 RuntimeException，就编译器而言，您可以从任何方法实现中抛出它。例如，您可以从 Collection.size() 的实现中抛出它。但是，这样的实现会违反契约(Contract)，因为 Collection.size() 的文档没有说这是允许的。

旁白:Java 的 Collections API 使用的方法有些争议(不过现在可能比首次引入时少)。在完美的世界中，接口(interface)不有可选操作，而是使用细粒度的接口(interface)。问题是 Java 既不支持推断的结构类型也不支持交集类型，这就是为什么尝试以“正确的方式”做事最终在集合的情况下变得极其笨拙。