-1

这是个好主意吗？如果没有，现在如何解决？

我认为添加一个会很有趣

final boolean identical(Obj obj){
   return (this==obj);
}

所以我们有一个改进的等于（逻辑等于）

boolean equals (Obj obj){
   return identical(obj); // by default, but its overrideable
}

这个问题源于另一个问题（A Mechanism for have different equals (physical equals andlogical equals) on objects in Collection）需要有一种方法来将相同指针列表与相同对象列表进行比较。有了这个想法，我们可以添加到 Collection 接口：

 coll.equals(coll2)
 coll.identical(coll2)
 coll.identicalElem(coll2){
      //current equals implementation of collections but calling identical to compare objects
 }

你怎么看？

4

4 回答 4

2

您发布的默认equals()实现已经是java.lang.Object. 用相同的实现覆盖它没有任何意义。

关于您添加到集合界面的 3 种方法：

coll.equals(coll2): 这个已经在Collection界面了。

coll.identical(coll2): 等同于coll == coll2，但可读性较差。我不明白这种方法的意义。

coll.identicalElem(coll2): 这个方法确实不存在，但是我从来没有需要过这样的方法，所以我认为它不应该把Collection的API弄得乱七八糟。你可以使用 Guava 的Equivalence来做到这一点：

Equivalence.identity().pairWise().equivalent(coll1, coll2);
于 2012-08-01T12:03:12.137 回答
2

我不知道您是否知道这一点，但标准 Java API 中已经存在 IdentityHashMap。此外，您可以使用 System.identityHashCode 生成对象的哈希码。

于 2012-08-01T11:54:32.260 回答
0

对象上现有的“等于”方法已经这样做了——对吗？

这是代码：

    public boolean equals(Object obj) {
        return (this == obj);
    }

因此，如果您为“等于”提供了一个实现，它会执行，如果没有（默认情况下），它使用“==”

于 2012-08-01T11:56:08.343 回答
0

这不是一个好主意，因为这equals(Object)是测试一个类的两个实例是否相等，而不是它们是否代表同一个实例（即它们的指针相等）。

如果你实现那个“改进的”equals 方法，你最终会得到类似的结果： new Rectangle(1, 2).equals(new Rectangle(1, 2))返回 false，这将是荒谬的。

此外，还有大量代码依赖于equals方法的当前定义（例如 HashMaps 使用它来解决不同对象的哈希码冲突）。没有什么特别的原因，事情会到处爆发。

您提出的identical方法也不会在现有==运算符上增加任何价值。

在我看来，在有意义的地方覆盖equals对象的方法（尽管我什至对此提出质疑），但您绝对不想建议在顶层更改它以及所有对象的默认行为。

于 2012-08-01T11:58:48.157 回答