Effective java3——覆盖equals方法的通用约定

最新推荐文章于 2024-04-21 15:33:54 发布

转载最新推荐文章于 2024-04-21 15:33:54 发布 · 363 阅读

Effective java 专栏收录该内容

9 篇文章

订阅专栏

本文深入探讨了Java中equals方法的使用规范及其常见错误，包括违反约定的情况与解决策略，旨在帮助开发者构建高效、一致的equals方法实现。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

满足下列四个条件之一的就不需要覆盖equals方法：

（1）类的每个实例本质上都是唯一的，如枚举等。

（2）不关心类是否提供了“逻辑相等”的测试功能。

（3）超类已经覆盖了equals方法，从超类继承过来的行为对于子类也是合适的。

（4）类是私有的或者包访问权限的，可以确定它的equals方法永远不会被调用。

当类具有自己特有的“逻辑相等”概念（不同于对象等同的概念），而且超类还没有覆盖equals方法以实现期望的行为时，就需要覆盖equals方法。在覆盖equals方法时，必须遵循以下的通用约定：

（1）自反性(reflexive)：对于任何非null的值x，x.equals(x)必须返回true。

（2）对称性（symmetric)：对于任何非null的值x和y，当且仅当y.equals(x)返回true时，x.equals(y)必须返回true。

（3）传递性（transitive)：对于任何非null的引用值x，y和z，如果x.equals(y)返回true，且y.equals(z)返回true，那么x.equals(z)也必须返回true。

（4）一致性（consistent)：对于任何非null的引用值x和y，只有equals的比较操作在对象中所用的信息没有被修改，多次调用x.equals(y)总会一致地返回相同的结果。

（5）非空性（Non-nullity)：对于任何非null的引用值x，x.equals(null)必须返回false。

这些约定看起来很简单，但是在实际编程中很容易违反这些约定，一旦违反这些约定，程序运行就会不正常，接下来通过例子展示违反约定的情况以及如何避免这些错误。

违反对称性的例子：

实现一个区分大小写的字符串，字符串由toString方法保存，但在equals比较操作中忽略大小写：

public final class CaseInsesitiveString{

private final String s;

pbulic CaseInsenitiveString(String s){

if(s==null){

throw new NullPointerException();

}

this.s = s;

}

@Override public boolean equals(Object o){

if(o instanceof CaseInsensitiveString){

return s.equalsIgnoreCase(((CaseInsensitiveString)o).s);

}

if(o instanceof String){

return s.equalsIgnoreCase((String)o);

}

return false;

}

我们使用如下的测试数据来测试这个equals方法：

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");

String s = "polish";

当调用cis.euqals(s)时调用的是CaseInsensitiveString类的equals方法返回ture，但是s.equals(cis)调用的是String类的equals方法返回false，不满足对称性。

解决这个错误的方法是将equals方法进行如下的重构：

@Override public boolean equals(Object o){

return o instanceof CaseInsensitiveString && ((CaseInsensitiveString)o).s.equalsIgnoreCase(s);

}

违反传递性的例子：

一个基本的Point类如下：

public class Point{

private final int x;

private final int y;

public Point(int x,int y){

this.x = x;

this.y = y;

}

@Override public boolean equals(Object o){

if(!(o instanceof Point)){

return false;

}

Point p = (Point)o;

return p.x == x && p.y == y;

}

现在想对Point类做扩展，为其添加颜色信息：

public class ColorPoint extends Point{

private final Color color;

public ColorPoint(int x,int y,Color color){

super(x,y);

this.color = color;

}

此时如果对ColorPoint调用equals方法，由于其没有覆盖equals方法，因此是直接调用从超类继承过来的equals方法，在比较过程中将颜色信息忽略，这样做虽然没有违反equals约定，但是不符合逻辑相等的期望，因此为ColorPoint提供如下的equals方法：

@Override public Boolean equals(Objet o){

if(! (o instanceo ColorPoint)){

return false;

}

return super.equals(o) && ((ColorPoint)o).color == color;

}

使用如下的测试数据测试equals方法：

Point p = new Point(1,2);

ColorPoint cp = new ColorPoint(1,2,Color.RED);

当p.equals(cp)时调用Point的equals方法，没有颜色信息，因此返回true，当cp.equals(p)是调用ColorPoint的equals方法时，则返回false，不满足对称性，可以通过如下重构equals的方法修复这个问题：

@Override public Boolean equals(Object o){

if(!(o instanceof Point)){

return false;

}

if(!(o instanceof ColorPoint)){//不带颜色的Point，使用Point的equals方法比较

return o.equals(this);

}

return super.equals(o) && ((ColorPoint)o).color == color;

}

上述方法保证了对称性，我们可以使用以下测试数据来进行测试：

ColorPoint p1 = new ColorPoint(1,2,Color.BLUE);

Point p2 = new Point(1,2);

ColorPoint p3 = new ColorPoint(1,2,Color.RED);

当p1.equals(p2)时返回true，p2.equals(p3)时返回true，p1.equals(p3)时返回false，不满足传递性。

这个问题是面向对象语言中关于等价关系的一个基本问题：无法在扩展可实例化的类的同时，既增加新的值组件，同时又保留equals的约定。

解决这个问题的方法是：面向对象编程中，组合优先于继承，现在的ColorPoint类不再继承Point类，而是通过一个引用组合它，重构之后的代码如下：

public class ColorPoint{

private final Point point;

private final Color color;

public ColorPoint(int x,int y,Color color){

if(Color == null){

throw new NullPointerException();

}

point = new Point(x,y);

this.color = color;

}

@Override public Boolean equals(Object o){

if(!(o instanceof ColorPoint)){

return false;

}

ColorPoint cp = (ColorPoint)o;

return cp.point.equals(point) && cp.color.equals(color);

}

JDK中的java.sql.Timestamp对java.util.Data进行了扩展，并增加了nanosecond域，Timestamp的equals方法实现确实违反了对称性原则，JDK文档中的免责声明如下：

java.sql.Timestamp由java.util.Date和单独的毫微妙值组成。只有整数秒才会存储在java.util.Date组件中。小数秒（毫微妙）是独立存在的。传递不是java.sql.Timestamp实例的对象时，Timestamp.equals(Object)方法永远不会返回true，因为日期的毫微秒组件是未知的。因此，相对于java.util.Date.equals(Object)方法而言，Timestamp.equals(Object)方法是不对称的。此外，hashcode方法使用底层java.util.Date实现并因此在其计算中不包括毫微秒。

鉴于Timestamp类和上述java.util.Date类之间的不同，建议代码一般不要将Timestamp值视为java.util.Date的实例。Timestamp和java.util.Date之间的基础关系实际上指的是实现继承，而不是类型继承。

所以当把Timestamp类和Date对象用于同一一个集合对象或者其他混合使用时，可能会引起难以调试的问题，在编程中建议大家不要将二者混用。

避免违反一致性原则：

在equals方法中不要依赖不可靠的资源，例如java.net.URL的equals方法依赖与对URL中主机IP地址的比较，但是网络中主机IP地址有可能是变化的，因此java.net.URL的equals方法难以保证一致性原则。

避免违反空值性原则：

这个原则容易避免，很多人喜欢使用下面方式避免空值：

@Override public boolean equals(Object o){

if(o == null){

return false;

}

.....

}