集合框架中的接口

由于两个正确答案未能说服你，我将尝试解释。

接口定义了契约 - 即它们定义了实现者要做什么（和绑定）做什么，这样你就知道，每当你通过接口引用一个对象时，它都有一个严格定义的行为，无论它是如何实现的。

现在，这个合同分为两部分：

• 方法签名 - 方法签名是由编译器强制执行的元素 - 所有实现者都必须符合接口定义的所有方法签名
• 记录的行为 - 当方法比其方法签名更多时，特殊行为被记录下来。它再次告诉接口的客户端对所有实现者的期望，尽管它并没有在技术上迫使实现者遵守它。

以下是具体/示例：CollectionSet

• 如果您将对象称为 ，那么您对行为一无所知 - 它是否允许重复Collectionadd
• 如果将对象称为 ，则可以确定不允许重复项。Set

这种区别是由重新定义的方法的javadoc做出的。add

Set.add 优化 Collection.add 的合约。来自后者的Javadoc：

支持此操作的集合可能会限制可以添加到此集合中的元素。特别是，某些集合将拒绝添加 null 元素，而其他集合将对可能添加的元素类型施加限制。集合类应在其文档中明确指定对可以添加的元素的任何限制。

这就是 Javadoc 中所做的，其中它声明例如，重复的元素不会添加到集合中。Set.add

更新：关于合约和接口

（包括并扩展我在下面的评论，以完善这个答案。

方法的协定正式或非正式地指定调用方应提供的内容作为该方法的输入，以及方法调用的保证结果是什么。例如，合约可能声明不需要任何参数，如果该方法传递了一个参数，它将抛出一个 .集合框架中方法的Javadoc就是这种契约的很好的例子。nullnullNullPointerException

请注意，某些语言允许甚至要求正式定义协定，因此协定被编译到代码中并主动强制执行运行时。埃菲尔就是这样一种语言。但是，Java没有这样的工具。Javadoc中定义的契约不是正式的，甚至没有为它们定义的严格格式。这些仅用于人类阅读，JVM没有注意到。因此，在Java中破坏契约可能不会立即引起注意，只有当产生的错误开始出现时才会立即注意到。

可以为具体类方法和抽象/接口方法定义协定。接口的协定（应该）绑定到其所有实现。即，等都必须履行合同（并可能进一步完善它）。不按照合同行事的实现打破了Liskov替换原则。HashSet.addTreeSet.addLinkedHashSet.addSet.addSet.add