java 什么重写了equals_浅谈java 重写equals方法的种种坑

重写java object类的equals方法

覆盖equals方法请遵守约定

什么情况下要覆盖equals方法

容易违反的对称性

不易察觉的传递性

覆盖equals请遵守通用约定

似乎覆盖equals方法看起来似乎是一件平常甚至极其简单的事情,

但是有许多覆盖方式会导致错误,并且会表现出超出预期的行为,

而有可能数小时也无法找到错误的位置。(比如说把参数改成了非Object类型)

1. 类的每一个实例在本质上都是唯一的

( 从内存的角度来讲是这样的),对于代表活动而不是值(value)的类来说更是如此,

例如Thread。

Object提供equals的实现对于这些类来说是正确的行为

2. 类没有必要提供“逻辑相等”的测试功能

3.超类已经覆盖了equals方法,超类的行为对于子类来说同样也是合适的

4.类是私有的或者是包级私有的,可以确定它的equals方法永远不会被外界调用

如果非常想规避风险,可以覆盖equals方法,

来确保来自Object或者超类的方法永远不会被意外调用。

那么什么时候应该覆盖equals方法

如果类具有自己特有的“逻辑相等”概念(不同于对象等同的概念)

而且超类没有覆盖equals方法。这通常属于"值类"(value class)的情形

例如 一个圆 Circle类,内有一个私有的成员变量radius半径

可以认为,radius相等代表了两个实例在逻辑上相等(或许可以再加上坐标)

再看String类,程序员在利用equals方法比较值对象的引用时,

更希望知道它们逻辑上是否相等,而不希望知道它们到底是不是同一个对象

为满足要求,不仅必须覆盖equals方法,

而且这样做也使得这个类的实例

可以被用作映射表 (map) 的键 (key) ,或者集合set的元素,

使其表现出符合预期的行为

注意:有一种“值类”不需要覆盖equals方法

即实例受控,甚至于单例模式,

确保每个实例的“值”至多只存在一个对象,甚至仅能存在一个实例

(好像太严格了,不过只能存在一个对象有什么可比的呢,就像客户端只能有一个连接服务器的socket类实例一样)

覆盖equals时请遵守通用约定

自反性,对称性以及传递性是最基础的约定

x.equals(x) = x.equals(x) (好像很傻)

x.equals(y) = y.equals(x)(这也是最容易出现问题的地方)

x.equals(y) = y.equals(z) 那么x.equals(z) == true

一致性:

对于任何非null引用值x和y,只要equals方法的比较操作在对象中引用的信息没有被修该,多次调用x.equals(y)返回的结果一致

对于任何非null的引用值x,x.equals(null)必须返回false

下面是一个不区分大小写字符串类的定义(注意 是反例!!违反了对称性)

public class CaseInsensitiveString {

private final String s;//存有不可变字符串s

public CaseInsensitiveString(String s) {

this.s = s;

}

@Override //重写equals方法,请注意参数为Object

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方法中的参数Object o,一定不要定义成其他类型!!

在绝大多数情况都要加上一句instanceof 来给o 赋予类型!!!

这个类的equals方法看起来设计的很有想法,不仅和自身比较,也希望和String类型进行比较。

//也确实看起来实现了功能

public static void main(String[] args)

{

//不区分大小写的字符串Point

CaseInsensitiveString cis = new CaseInsensitiveString("Point");

String s = "point";

System.out.printf(cis.equals(s)+"");//true

}

但是 s.equals(cis)却返回了false

//s.equals(cis)却返回了false

public static void main(String[] args)

{

CaseInsensitiveString cis = new CaseInsensitiveString("Point");

String s = "point";

System.out.printf(cis.equals(s)+"");//true

System.out.printf(s.equals(cis)+"");//false

}

虽然CaseInsensitiveString类中的equals方法知道普通的字符串对象

但是String类中的equals方法并不知道不区分大小写的字符串,

导致了超出预期的错误

显然违反了对称性。

一旦违反了equals约定,当其他对象面对你的对象是,你完全不知道这些对象的行为会怎样

为了解决这个问题,只需要把企图和String互相操作的代码删除就可以了

public class CaseInsensitiveString {

private final String s;//存有不可变字符串s

public CaseInsensitiveString(String s) {

this.s = s;

}

@Override //重写equals方法,请注意参数为Object

public boolean equals(Object o) {

if (o instanceof CaseInsensitiveString)//判断传入的是同类型的参数

{

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

}

/*删除掉的与String互操作的代码*/

return false;

}

}

考虑这样一种情况

有一个坐标类,内有成员变量x和y

并提供equals方法

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)

{

Point p = (Point)o;

return (this.x == p.x && this.y==p.y);

}

return false;

}

}

好像简单到不能再简单的定义

那么扩展(继承)一下,为这个点添加颜色信息

public class ColorPoint extends Point{

private final Color color;

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

{

super(x,y);

this.color=color;

}

}

现在考虑一下

equals方法是什么样的呢?

如果子类ColoePoint完全不提供equals方法,而是直接使用父类的equals方法

在equals做比较的时候颜色信息就被忽略掉了。

虽然这么做不会违反equals约定

但显然是无法接受的。

那么就重写一个equals方法。只有当坐标点x,y相同且颜色也相同时

equals才返回true

public class ColorPoint extends Point{

private final Color color;

public ColorPoint(int x,y);

this.color=color;

}

@Override

public boolean equals(Object o)

{

if(o instanceof ColorPoint)

{

return (super.equals(o)&& this.color==

( (ColorPoint) o ).color);//使用父类的equals方法

}

return false;

}

}

这个方法的问题在于,比较普通点(没有颜色的Point实例)和

有色点(ColorPoint实例)比较,以及相反的情况时可能会得到不同的结果

前一种忽略的颜色信息,而后一种总时返回false(因为参数类型不正确)

public static void main(String[] args)

{

Point p = new Point(1,2);

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

System.out.printf(p.equals(cp)+"");//true

System.out.printf(cp.equals(p)+"");//false

}

可以尝试以ColorPoint.equals在进行“混合颜色比较时”忽略颜色信息

但这样做确实提供了对称性,但却牺牲了传递性。

那该怎么解决???

事实上,这是面向对象语言中关于等价关系的一个基本问题。

我们无法在扩展可实例化的类的同时,既增加新的组件,同时又保留equals约定虽然没有一种令人满意的办法既可以扩展可实例化的类,又增加组件,但还有一种不错的方法。复合优先于继承

我们不再让ColorPoint继承Point,

而是在ColorPoint类中添加一个私有的Point域

以及一个公有的视图(view)方法

此(view)方法返回一个与该色点处在相同位置的普通Point对象。

public class ColorPoint{

private final Color color;

private final Point point;

public ColorPoint(int x,Color color)

{

point = new Point(x,y);

this.color=color;

}

/*view*/

public Point asPoint()

{

return point;

}

@Override

public boolean equals(Object o)

{

if(o instanceof ColorPoint)

{

ColorPoint cp =(ColorPoint)o;

return this.point.equals(cp.point)&&

this.color.equals(cp.color);//调用Point以及Color类的equals方法

}

//那么有色点与无色点会被判断为不相同而返回false

return false;

}

}

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

总结

如果觉得编程之家网站内容还不错,欢迎将编程之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。

如您喜欢交流学习经验,点击链接加入交流1群:1065694478(已满)交流2群:163560250

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值