关于重写的equals方法

Lucare 发布于 2016/06/22 23:20
阅读 335
收藏 1

今天看到别人重写的这个equals方法,我提出红框中的代码是不是可以换成

if(!(obj instanceof ImageCode))
  return false



结果很多人攻击我,说这么写是不对的,但是我就想知道哪里不对了,什么情况下会出错,希望懂的出来解释下。

加载中
0
前世疯狂
前世疯狂

原因是instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例,通过返回一个布尔值来指出,这个对象是否是这个特定类或者是它的子类的一个实例。

也就是说你使用instanceof去判断两个ImageCode对象或其子对象实例时总是会返回true,表示他们都是ImageCode的实例或父类是ImageCode,但并不意味着这两个实例相同。

不知道这么解释说清楚了没有

0
Lucare
Lucare

引用来自“前世疯狂”的评论

原因是instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例,通过返回一个布尔值来指出,这个对象是否是这个特定类或者是它的子类的一个实例。

也就是说你使用instanceof去判断两个ImageCode对象或其子对象实例时总是会返回true,表示他们都是ImageCode的实例或父类是ImageCode,但并不意味着这两个实例相同。

不知道这么解释说清楚了没有

如果这么说,你用上面的写法。当你在子类中增加了一个其他的方法,你主要还是生成验证码,上面的equals是为了保证验证码内容不重复,你用getClass比较直接会返回false,但实际上你的code可能是一样的。
0
前世疯狂
前世疯狂

引用来自“前世疯狂”的评论

原因是instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例,通过返回一个布尔值来指出,这个对象是否是这个特定类或者是它的子类的一个实例。

也就是说你使用instanceof去判断两个ImageCode对象或其子对象实例时总是会返回true,表示他们都是ImageCode的实例或父类是ImageCode,但并不意味着这两个实例相同。

不知道这么解释说清楚了没有

引用来自“Lucare”的评论

如果这么说,你用上面的写法。当你在子类中增加了一个其他的方法,你主要还是生成验证码,上面的equals是为了保证验证码内容不重复,你用getClass比较直接会返回false,但实际上你的code可能是一样的。
你说的是的,这里就看你的equals中穿插的业务逻辑到底时准备如何判定了。我们通常从纯代码的逻辑角度出发的话不同的类实例是不应该equals成立的即使两个类是存在父子级,而instanceof这个用在equals中无法替代原代码。如果单纯是想通过实例中的code属性去确保验证码内容一致即可,那建议使用其他方法而不是重载equals
Lucare
Lucare
那重写equals到底推荐非空加getClass比较还是用instanceof呢,还要考虑继承的问题吗。
0
Ambitor
Ambitor

引用来自“前世疯狂”的评论

原因是instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例,通过返回一个布尔值来指出,这个对象是否是这个特定类或者是它的子类的一个实例。

也就是说你使用instanceof去判断两个ImageCode对象或其子对象实例时总是会返回true,表示他们都是ImageCode的实例或父类是ImageCode,但并不意味着这两个实例相同。

不知道这么解释说清楚了没有

引用来自“Lucare”的评论

如果这么说,你用上面的写法。当你在子类中增加了一个其他的方法,你主要还是生成验证码,上面的equals是为了保证验证码内容不重复,你用getClass比较直接会返回false,但实际上你的code可能是一样的。

引用来自“前世疯狂”的评论

你说的是的,这里就看你的equals中穿插的业务逻辑到底时准备如何判定了。我们通常从纯代码的逻辑角度出发的话不同的类实例是不应该equals成立的即使两个类是存在父子级,而instanceof这个用在equals中无法替代原代码。如果单纯是想通过实例中的code属性去确保验证码内容一致即可,那建议使用其他方法而不是重载equals
你可以的 小伙子,没什么问题,因为这个题目改写equals方法 就是为了判断 ImageCode对象的code是否相同,只要code相同 就代表两个对象是同一个数据,跟是不是它子类没什么关系。相当于 如果我用ArrayList存一个数字为1的数据,然后我还有一个LinkedList里面也存着为1的数字,然后我需要判断这两个list是否相同 所以 我会调用ArrayList.equals(LinkedList) 如果jdkArrayList.equals的写法是比对class 而不是
if (!(o instanceof List)) return false;
那么 会直接返回false的,这样就太死板 太2了。
Lucare
Lucare
回复 @Ambitor : 好的,谢谢了
Ambitor
Ambitor
回复 @Lucare : 还是那句话,不要太过于纠结这些细节,你要明白的是弄懂这个东西,至于现在是怎么写 不是重要的,因为每个leader或公司框架以及规范都是不一样的,你觉得你有必要因为这个得罪leader?又不是大不了的事 万一你下次遇到一个leader又让你写成instanceof呢, 小细节可以忽略 大方向把控好。
Lucare
Lucare
回复 @Ambitor : 关键他们说他们那种写法就是对的,用instanceof就是错的,叫我按他们的写就行了。
Ambitor
Ambitor
@Lucare 自动生成- -! 那就不要说了 自己弄明白就好 这些无关同样的问题不要纠结,技术提高了 说话就有分量啦
Lucare
Lucare
基础太差,我也说不过人家,别人说这个equals是自动生成的,叫我不要钻牛角尖了。
0
前世疯狂
前世疯狂

引用来自“前世疯狂”的评论

原因是instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例,通过返回一个布尔值来指出,这个对象是否是这个特定类或者是它的子类的一个实例。

也就是说你使用instanceof去判断两个ImageCode对象或其子对象实例时总是会返回true,表示他们都是ImageCode的实例或父类是ImageCode,但并不意味着这两个实例相同。

不知道这么解释说清楚了没有

引用来自“Lucare”的评论

如果这么说,你用上面的写法。当你在子类中增加了一个其他的方法,你主要还是生成验证码,上面的equals是为了保证验证码内容不重复,你用getClass比较直接会返回false,但实际上你的code可能是一样的。

引用来自“前世疯狂”的评论

你说的是的,这里就看你的equals中穿插的业务逻辑到底时准备如何判定了。我们通常从纯代码的逻辑角度出发的话不同的类实例是不应该equals成立的即使两个类是存在父子级,而instanceof这个用在equals中无法替代原代码。如果单纯是想通过实例中的code属性去确保验证码内容一致即可,那建议使用其他方法而不是重载equals
从重写equals的角度来说代码逻辑中已经限定了是在同是ImageCode的前提下进行比较的,你用instanceof就改变了代码原逻辑,你的代码确实有问题。从你描述的单纯通过code进行比较即可认为两者相等的判断,我认为这是业务逻辑的限定,这个不能取代equals这个方法,就像前面提到的,你可以新增其他的方法,例如equalCode()来通过code进行业务逻辑的判断,那你前面的限制代码是否还需要都是可以根据你实际业务场景来调整的。我的结论是:从重写equals时使用原代码,你之前代码确实有问题,业务逻辑的限制不应取代equals是否真实相等的比较
Lucare
Lucare
受教了!
返回顶部
顶部