【发布时间】：2011-02-21 10:34:39
【问题描述】：
我对 Java 中的这两个接口有疑问。 Set 扩展 Collection，但不添加任何内容。它们完全相同。 我在这里错过了什么吗？
【问题讨论】：
标签： java collections interface set
【发布时间】：2011-02-21 10:34:39
【问题描述】：
Set 不允许重复。
这是语义上的差异，而不是句法上的差异。
【讨论】：
-
+1：规范对于接口和方法定义一样重要。
-
所以我不明白。为什么需要 Set
。 OO 方面感觉不对。 -
在 Set 和 Collection 中插入两次相同的对象。
来自Collection的文档：
一个集合代表一组对象，称为它的元素。 有些集合允许重复元素，而有些则不允许。有些是有序的，有些是无序的。
来自Set的文档：
一个不包含重复元素的集合。 更正式地说，集合不包含一对元素
e1和e2使得e1.equals(e2)和最多一个null元素。正如其名称所暗示的那样，此接口对数学集抽象进行建模。
这应该澄清Set 和（更通用的接口）Collection 之间的区别。
【讨论】：
好问题。我想与Collection 的概念相比，明确地为Set 的概念提供接口的主要目的是为了真正正式区分这些概念。假设您正在编写一个方法
void x(Collection<?> c);
你不会像你在写作那样对你想要得到什么参数有同样的想法
void x(Set<?> s);
第二种方法期望Collections 最多包含每个元素一次（即Sets）。这与第一种方法有很大的语义差异，它不关心它是否接收Sets、Lists 或任何其他类型的Collection
如果您仔细观察，Set 方法的 Javadoc 也有所不同，明确显示了在谈论 Collection 或 Set 时发挥作用的不同概念
【讨论】：
-
不过，我还是不明白。如果 Set
只是通过它的名字来暗示我们有一个没有多个对象的集合，并且没有通过任何代码更改来强制它，我们为什么需要它。如果我正在实现集合，我可以用一个暗示该行为的名称来调用我的类。 -
正是出于我提到的原因（以及这里的其他原因）。因为那时，我可以正式在我的方法中期待一个
Set参数，而不仅仅是一个普通的Collection。这是众多原因之一 -
我正在关注这个线程。如果您能引用一个可以方便进一步参考的工作示例，我们将不胜感激。
-
嗯，举个例子……好吧，去看看
java.util.Map<K, V>接口。它有这两种方法，例如：Set<K> keySet()和Collection<V> values()。众所周知，每个键在Map中只能包含一次，并且键的顺序无关紧要。所以Set是比Collection更好的选择，因为它正式传达这一事实。对于values()，情况有所不同。我们不知道一个值是否可以在一个映射中多次包含，并且顺序也无关紧要。所以最好的选择是Collection
Collection 是一个更通用的接口，由 Lists、Queues、Sets 等组成。
查看“所有已知子接口”部分here。
【讨论】：
一切都在文档中：
Set - 一个集合，不包含 重复元素。更正式地说， 集合不包含元素对 e1 和 e2 使得 e1.equals(e2)，并且在 最多一个空元素。正如所暗示的那样 它的名字，这个接口模拟了 数学集合抽象。
和
Collection - 中的根接口 集合层次结构。一个集合 表示一组对象，已知 作为它的元素。一些收藏 允许重复的元素和其他的 不是。有些是订购的，有些是订购的 无序的。 SDK 不提供 这个的任何直接实现 接口：它提供实现 更具体的子接口，如 设置并列出。这个界面是 通常用于传递集合 并在哪里操纵它们 需要最大的通用性。
只是为了区分实现和未来的使用。
这来自集合论和字典
【讨论】：
此外，Set 文档为.equals 定义了一个合同，其中说“只有其他 Set 可能等于此 Set”。如果我们无法通过类型识别其他 Set（使用 instanceof），就不可能实现这一点。
如果仅用于equals()，则可以为Collection 提供allowsDuplicates() 方法。但经常有 API 想说“请不要给我重复”或“我保证这不包含重复”的情况，而在 Java 中没有办法在方法声明中说“请只给集合allowsDuplicates() 方法返回 false”。因此是附加类型。
【讨论】：