与集合相等且可比 [英] Equals and Comparable with Sets

查看:114
本文介绍了与集合相等且可比的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在此处发布了一些代码,这些代码可以正确解决发布者遇到的问题。 OP希望删除重复项,并将某些特殊项放在列表的顶部。我使用了 TreeSet 和特殊的 Comparable 类,该类包装了 Locale 他们正在与他们一起实现他们想要的东西。

I posted some code here which correctly solved a problem the poster had. OP wanted to remove duplicates and bring certain special items to the top of a list. I used a TreeSet with a special Comparable class which wrapped the Locale they were working with to achieve what they wanted.

然后我开始思考……就像你做的那样……我通过返回<$来消除重复项c $ c> 0 来自 compareTo 方法,而不是通过 equals 实现,因为需要正确地在 Set 中指示重复项(来自定义 $ 的 )。

I then got to thinking ... as you do ... that I was eliminating duplicates by returning 0 from the compareTo method, not by returning true from an equals implementation as one would need to do to correctly indicate a duplicate in a Set (from the definition of a Set).

我不反对使用这种技术,但是我使用的可能是未公开文档的功能吗?我可以肯定地说,继续做这种事情会继续有效吗?

I have no objection to using this technique but am I using what might be considered an undocumented feature? Am I safe to assume that doing this kind of thing going forward will continue to work?

推荐答案

看来这很好 TreeSet的JavaDoc (粗体显示):

It seems like this is pretty well documented in JavaDoc of TreeSet (bold mine):


请注意,该顺序由集合(无论是否是显式)维护如果要正确实现 Set 接口,则必须与equals 保持一致。 (有关与equals的精确定义,请参见可比较比较器。)因为 Set 接口是根据 equals 操作定义的,而 TreeSet 实例使用其 compareTo (或比较)方法执行所有元素比较,因此,从设置,相等。 集合的行为是明确定义的,即使其排序与等式不一致;只是不遵守 Set 接口的一般合同。

Note that the ordering maintained by a set (whether or not an explicit comparator is provided) must be consistent with equals if it is to correctly implement the Set interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a TreeSet instance performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the set, equal. The behavior of a set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.

以下是仅(?)的示例实现 Comparable 但与 equals()

Set<BigDecimal> decimals = new HashSet<BigDecimal>();
decimals.add(new BigDecimal("42"));
decimals.add(new BigDecimal("42.0"));
decimals.add(new BigDecimal("42.00"));
System.out.println(decimals);

十进制最后有三个值,因为 42 42.0 42.00 不尽相同与 equals()有关。但是,如果将 HashSet 替换为 TreeSet ,则结果集中仅包含1个项目( 42 -恰好是第一个添加的),因为使用 BigDecimal.compareTo()

decimals at the end have three values because 42, 42.0 and 42.00 are not equal as far as equals() is concerned. But if you replace HashSet with TreeSet, the resulting set contains only 1 item (42 - that happened to be the first one added) as all of them are considered equal when compared using BigDecimal.compareTo().

这表明当使用与<$ c不一致的类型时, TreeSet 处于 中断状态$ c> equals()。它仍然可以正常工作,并且所有操作都定义明确-只是不遵守 Set 类的约定-如果两个类的值不等于 equal( ),它们不视为重复项。

This shows that TreeSet is in a way "broken" when using types not consistent with equals(). It still works properly and all operations are well-defined - it just doesn't obey the contract of Set class - if two classes are not equal(), they are not considered duplicates.

  • What does comparison being consistent with equals mean ? What can possibly happen if my class doesn't follow this principle?

这篇关于与集合相等且可比的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆