集合框架中的接口

发布于 2024-10-08 22:14:59 字数 223 浏览 2 评论 0原文

我的问题是

Interface Set 有方法 add(E e) 并且它扩展了接口 Collection。接口Collection也有方法add(E e) 那么为什么我们需要在接口 Set 中使用相同的方法，因为它已经扩展了接口Collection。目的是什么？我被困住了

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

摇划花蜜的午后 2024-10-15 22:14:59

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

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

现在，这个契约分为两部分：

方法签名 - 方法签名是由编译器强制执行的元素 - 所有实现者都必须符合接口
记录的行为定义的所有方法签名 - 当方法的内容超出其本身的内容时方法签名，记录了特殊行为。它再次告诉接口的客户端对所有实现者的期望，尽管它在技术上并不强制实现者遵守它。

下面是具体的 Collection / Set 示例：

如果您将一个对象引用为 Collection，那么您对以下内容一无所知add 的行为 - 是否允许重复，
如果您将对象引用为 Set，那么您可以确定不允许重复。

这种区别是由 redefine add 方法的 javadoc 实现的。

回复收藏 0 原文

等往事风中吹 2024-10-15 22:14:59

设置.add 完善了 Collection.add。来自后者的 Javadoc：

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

这就是 Set.add 的 Javadoc 中所做的事情，其中指出，例如，不会将重复元素添加到集合中。

更新：关于契约和接口

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

方法的契约指定 - 正式或非正式 - 调用者期望提供作为输入的内容对于该方法，以及该方法调用的保证结果是什么。例如，合约可能声明不需要 null 参数，并且如果该方法传递了 null 参数，它将抛出 NullPointerException。 Collection 框架中方法的 Javadoc 是此类契约的好例子。

请注意，某些语言允许甚至要求契约的正式定义，因此契约被编译到代码中并主动执行运行时。 Eiffel 就是这样一种语言。然而，Java 没有这样的功能； Javadoc中定义的契约并不正式，甚至没有为它们定义严格的格式。这些仅供人类阅读，JVM 不会注意到。因此，在 Java 中违反契约可能不会立即被注意到，只有稍后导致的错误开始出现时才会被注意到。

可以为具体类方法和抽象/接口方法定义契约。接口的契约（应该）绑定到它的所有实现。即HashSet.add、TreeSet.add、LinkedHashSet.add等都必须履行Set.add的约定>（并可能进一步完善）。不按照 Set.add 契约行事的实现会破坏 Liskov替换原则。

Set.add refines the contract of Collection.add. From the latter's Javadoc:

Collections that support this operation may place limitations on what elements may be added to this collection. In particular, some collections will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. Collection classes should clearly specify in their documentation any restrictions on what elements may be added.

That's what is done in the Javadoc of Set.add, where it states that e.g. duplicate elements are not added to the set.

Update: on contracts and interfaces

(including and extending my comments below to round out this answer.)

The contract of a method specifies - formally or informally - what the caller is expected to provide as input for that method, and what is the guaranteed outcome of the method call. E.g. the contract may state that no null parameters are expected, and if the method is passed a null parameter, it will throw a NullPointerException. The Javadoc of methods in the Collection framework are good examples of such contracts.

Note that some languages allow or even require the formal definition of contracts, thus the contracts are compiled into the code and actively enforced runtime. Eiffel is such a language. However, Java has no such facility; the contracts defined in Javadoc are not formal, there is not even a strict format defined for them. These are meant only for human reading, left unnoticed by the JVM. Thus, breaking a contract in Java may not be immediately noticeable, only later when the resulting bugs start to appear.

Contracts can be defined both for concrete class methods and abstract/interface methods. The contract of an interface is (should be) binding to all of its implementations. I.e. HashSet.add, TreeSet.add, LinkedHashSet.add etc. all must fulfill the contract of Set.add (and may further refine it). An implementation which does not behave according to the contract of Set.add breaks the Liskov substitution principle.

回复收藏 0 原文