我知道根据.equals()，Set只允许一个对象的实例存在，并且如果您已经拥有相等的对象，您不应该需要从Set中获取对象，但我仍然想要一个.get()方法，它可以返回Set中与给定参数相等的对象实例（或null）。
有关其设计原因的任何想法/理论？
通常，我必须通过使用Map并使键和值相同或类似的方法来绕过此问题。
编辑：到目前为止，我认为人们不理解我的问题。 我想要的是已经在集合中的确切对象实例，而不是.equals()返回true的可能不同的对象实例。
至于为什么我希望出现这种行为，通常.equals()不能考虑对象的所有属性。 我想提供一些虚拟查找对象，并获取Set中的实际对象实例。
get(Object)看起来不太可信，但底层意图并未无关紧要。equals(Object)。我们只需看看集合接口便知道这一点。例如，ArrayList和LinkedList可以相等，它们各自的内容仅需要相同且顺序也相同即可。public interface Collection<E> extends ... {
...
public E findMatch(Object o) throws UnsupportedOperationException;
...
}
WeakHashMap不适用，因为它持有值的强引用。 - supercatNSSet 类包含了 -containsObject: 方法以测试一个对象是否被包含在其中并返回一个布尔值，以及 -member: 方法来获取与给定对象相等的对象。OCaml标准库的 Set 包含了 mem 方法用于测试成员资格和 find 方法来获取相等的元素。 - newacct我在几年前的Java论坛上也有同样的问题。他们告诉我Set接口是已经定义好的，不能更改，因为这会破坏Set接口当前的实现。然后，他们开始说一些胡言乱语，就像你在这里看到的：“Set不需要get方法”，并开始向我灌输Map必须始终用于从Set中获取元素的观念。
如果您仅将Set用于数学运算，例如交集或并集，则可能只需要contains()方法。但是，在集合中定义Set是用于存储数据的。我使用关系数据模型解释了需要在Set中使用get()方法。
接下来，一个SQL表就像一个类。列定义属性（Java中称为字段），记录表示类的实例。因此，对象是字段的向量。其中一些字段是主键。它们定义对象的唯一性。这就是Java中contains()方法的作用：
class Element {
public int hashCode() {return sumOfKeyFields()}
public boolean equals(Object e) {keyField1.equals(e) && keyField2.equals(e) && ..}
你看，数据是带有标识存储的。不是标识指向数据，而是数据带有标识。他接着说：本章大部分内容都致力于研究一个非常简单的搜索问题：如何找到已经存储了给定标识的数据。
看起来他开始讲述映射。但是， 一般来说，我们假设已经存储了一组N个记录，并且问题是定位适当的记录。通常，我们要求N个键不同，以便每个键唯一地标识其记录。所有记录的集合称为“表”或“文件”，其中单词“表”通常用于指示小文件，“文件”通常用于指示大表。一个大文件或一组文件通常被称为“数据库”。搜索算法使用所谓的参数K进行演示，问题是找到具有K作为其键的记录。尽管搜索的目标是找到与K关联的记录中存储的信息，但本章中的算法通常忽略除键本身之外的所有内容。在实践中，一旦我们定位了K，就可以找到相关数据；例如，如果K出现在位置TABLE + i，则相关数据（或指向它的指针）可能位于位置TABLE + i + 1。例如，在数值应用程序中，我们可能想要找到f(x)，给定x和f值的表；在非数值应用程序中，我们可能想要找到给定俄语单词的英语翻译。
实体集是特定实体类型的所有实体的集合或组合[http://wiki.answers.com/Q/What_is_entity_and_entity_set_in_dbms]。单个类的对象共享其类属性。同样，DB中的记录也是如此。它们共享列属性。
集合的一个特殊情况是类范围，它是属于该类的所有对象的集合。类范围允许将类视为关系
... ["数据库系统概念"第6版]
基本上，类描述了所有实例共有的属性。关系型DB中的表也是如此。“您将拥有的最简单的映射是单个属性到单个列的属性映射。” 这就是我所说的情况。
我在证明对象和DB记录之间的类比（同构）时非常冗长，因为有些愚蠢的人不接受它（以证明他们的Set必须没有get方法）
你在回放中看到一些人不理解这个，认为使用 Set 和 get 是多余的？这是因为他们滥用了 map，在 set 的位置使用它，导致了冗余。他们调用 put(obj.getKey(), obj) 存储两个键：原始键作为对象的一部分和副本在 map 的键集中。这种重复就是冗余。它还涉及代码的更多膨胀，并浪费运行时消耗的内存。我不知道数据库内部如何，但良好设计和数据库规范化的原则表明这种重复是一个坏主意 - 必须只有一个真相来源。冗余意味着可能发生不一致：关键映射到具有不同键的对象。不一致是冗余的一种表现形式。Edgar F. Codd 提出了 DB 规范化 只是为了摆脱冗余及其引起的不一致性。老师们对规范化非常明确：规范化永远不会生成两个具有一对一关系的表。没有理论上的理由将单个实体分别放置在两个表的单个记录中的某些字段和另一个表的单个记录中的其他字段中。如果你已经从集合中“获取”了这个东西，那么你就不需要再使用get()方法获取它了，对吧？;-)
我认为你使用Map的方法是正确的。听起来你正在尝试通过equals()方法将对象“规范化”，而我一直都是使用像你建议的Map来实现这一点。
get(Object)从设置了A、B和C的集合中获取该实例。 - Boss Man我理解你可能会有两个相等的对象，但它们不是同一个实例。
比如：
Integer a = new Integer(3);
Integer b = new Integer(3);
在这种情况下，a.equals(b)是成立的，因为它们引用相同的内在值，但a！= b，因为它们是两个不同的对象。
还有其他Set的实现，例如IdentitySet，它在项目之间进行了不同的比较。
然而，我认为您正在尝试将不同的哲学应用于Java。如果您的对象相等（a.equals(b)），尽管a和b具有不同的状态或含义，那么这里肯定有问题。您可能需要将该类拆分为两个或多个语义类，这些类实现了一个公共接口-或者重新考虑.equals和.hashCode。
如果您有Joshua Bloch的Effective Java，请查看名为“重写equals时遵守通用合同”和“最小化可变性”的章节。
我认为，鉴于某些Set实现，你唯一的解决方案是迭代其元素以找到一个equals()相等的元素--然后你就有了与Set中匹配的实际对象。
K target = ...;
Set<K> set = ...;
for (K element : set) {
if (target.equals(element)) {
return element;
}
}
public <T> T findInSet(T findMe, Set<T> inHere){
inHere.retainAll(Arrays.asList(findMe));
if(!inHere.isEmpty){
return inHere.iterator().next();
}
return null;
}
这不是最有效地使用内存的方法，但它在功能和数学上是正确的。
我不确定您是在寻找Sets如此行为的解释，还是对其提出的问题的简单解决方案。其他答案处理了前者，因此这里提供一个后者的建议。
您可以遍历Set的元素，并使用equals()方法测试每个元素是否相等。它易于实现且几乎没有错误。显然，如果您不确定元素是否在集合中，请先使用contains()方法进行检查。
与例如HashSet的contains()方法相比，这并不高效，后者会“查找”存储的元素，但不会返回它。如果您的集合可能包含许多元素，甚至可能需要使用"更重"的解决方法，例如您提到的映射实现。但是，如果这对您很重要（我确实看到有这种能力的好处），那么它可能是值得的。
只需使用Map解决方案... TreeSet和HashSet也可以，因为它们由TreeMap和HashMap支持，所以这样做没有任何惩罚（实际上应该是最小的收益）。
您还可以扩展您喜欢的Set以添加get()方法。
[]]
Object fromSet = set.tailSet(obj).first();
if (! obj.equals(fromSet)) fromSet = null;
这就是你要找的功能。我不知道为什么Java把它隐藏起来了。