专栏首页程序亦非猿​第3章 对于所有对象都通用的方法

​第3章 对于所有对象都通用的方法

EffectiveJava阅读笔记心得系列第3章终于迎来完结篇,这一篇是对整一章节的汇总,对之前的条目有所更新,如果前面的已经看过,那么可以挑着看,如果没看过的话,可以重头看!

第2章在这里-->创建和销毁对象 本文有点长,而且文中又包含些代码,所以更推荐在PC端阅读

现在技术圈特别浮躁,也很容易被感染,看了很多文章很多博客,最后发现自己依然不懂,再加上每天信息爆炸,就特别容易浮躁

试问,你有多久没有安安静静看书了?

有时间的话,多看看书吧~

oh,另外,我的公众号也有了赞赏功能,还记得以前有同学给我留言说为什么没赞赏功能,哈哈,现在有了,如果你愿意支持我的话,非常欢迎,如果你不想有"肮脏的py交易的话",也没有关系啦!~~哈哈哈哈

好了,废话不多说了,看文!~~

第3章 对于所有对象都通用的方法

Object的设定是为了扩展,它的所有非final方法(equals hashCode toString clone finalize)都有明确的通用约定,因为它们被设计是要被覆盖(override)的 而在覆盖这些方法时,都有责任遵守这些通用的约定,否则,其他依赖这些约定的类(如HashMap&HashSet)就无法结合该类一起正常运作.

第8条 覆盖equals时请遵守通用约定

不覆盖equals

不覆盖equals的情况下,类的每个实例都与它自身相等,如果满足以下任何一个条件,就是所期望的结果:

  • 类的每个实例本质上都是唯一的
  • 不关心类是否提供了”逻辑相等”的测试功能
  • 超类已经覆盖了equals,从超类继承过来的行为对于子类也是合适的(要小心)
  • 类是私有的或是包级私有的,可以确定它的equals方法永远不会被调用 (不懂为什么)

讲得怪怪的

PS: 逻辑相等,就是逻辑上是相等的,比如id一样,判定它们相等,即使它们是两个不同的对象

什么时候应该覆盖equals

当类需要逻辑相等这个概念的时候就应该覆盖equals 比如要判断两个student是否是同一个人,这个时候我们就需要按需重写equals

通用约定

重写equals的时候就必须要遵守它的通用约定 equals方法实现了等价关系(equivalence relation):

  • 自反性(reflexive) 对于任何非null的引用值x,x.equals(x)必须返回true
  • 对称性(symmetric) 对于任何非null的引用值x和y,当且仅当y.equals(x)返回true时,x.equals(y)必须返回true
  • 传递性(transitive) 对于任何非null的引用值,x,y,z,如果x.equals(y)为true,并且y.equals(z)也返回true,那么x.equals(z)也必须返回true
  • 一致性(consistent) 对于任何非null的引用值x和y,只要equals的比较操作在对象中所用的信息没有被修改,多次调用x.equals(y)就会一致地返回true,或者false
  • 对于任何非null的引用值,x,x.equals(null)必须返回false

感觉又回到了学数学交换律什么的的时候了~

有些类(如集合,HashMap)与equals方法息息相关,所以重写的时候要仔细小心

高质量的equals

ej对equals提了几点建议:

  1. 使用==操作符检查”参数是否为这个对象的引用” 如果是,则返回true. 这只不过是一种性能优化,如果比较操作有可能很昂贵,就值得这么做 (平时没有用过,怎么样的比较操作算是昂贵的呢?)
  2. 使用instanceof操作符检查”参数是否为正确的类型” 如果不是,则返回false。
  3. 把参数装换成正确的类型。(这个比较好理解,instanceof检测后,一般都会强转成所需类型)
  4. 对于该类中的每个『关键』域,检查参数中的域是否与对象中对应的域相配。(比如学生类有学号,班级,姓名这些重要的属性,我们都需要去比对)
  5. 当你编写完成了equals方法之后,应该问自己是哪个问题:它是否是对称的、传递的、一致的?

另外EJ还告诫我们覆盖equals的时候总要覆盖hashCode(见第9条)

小结

最后按照上诉建议,用一个Student类来总结一下equals的写法:

public class Student {
   public String name;
   public String className;
   @Override
   public boolean equals(Object obj) {
       //对于一个null的对象 我们总是返回false
       if (null == obj) {
           return false;
       }
       // 利用instanceof检查类型后,强转
       if (obj instanceof Student){
           Student other = (Student) obj;
           //再对关键的属性做比较 得出结论
           if (name.equals(other.name) && className.equals(other.className)) {
               return true;
           }
       }
       return false;
   }
}

equals是一个看上去简单,实则是个比较容易犯错的方法,需要小心仔细

第9条 覆盖equals时总要覆盖hashCode

覆盖了equals方法,也必须覆盖hashCode方法,if not,就违反了hashCode的通用约定,会导致无法跟基于散列的集合正常运作.

Object通用约定(在Object类中的注释即是):

  • 在应用程序的执行期间,只要对象的equals方法的比较操作所用到的信息没有被修改,那么对这同一个对象调用多次,hashCode方法都必须始终如一地返回同一个整数.在同一个应用程序的多次执行过程中,每次执行所返回的整数可以不一致.
  • 如果两个对象根据equals方法比较是相等的,那么调用这两个对象中任意一个对象的hashCode方法都必须产生同样的整数结果.(即equals相等,那么hashCode一定相等,需要注意的是,反过来不一定成立,即hashCode相等不代表equals相等)
  • 如果两个对象根据equals方法比较是不相等的,那么调用这两个对象中任意一个对象的hashCode方法,则不一定要产生不同的整数结果.但是程序员应该知道,给不相等的对象产生截然不同的证书结果,有可能提高散列表(hash table)的性能.

不重写hashCode带来的问题

正如之前提到的,hashCode其实主要用于跟基于散列的集合合作 如HashMap会把相同的hashCode的对象放在同一个散列桶(hash bucket)中,那么即使equals相同而hashCode不相等,那么跟HashMap一起使用,则会得到与预期不相同的结果.

具体是怎么样的不同的效果?来看一段代码: PS:Student类是第8条里的类,重写了equals

public static void main(String[]args) {
   Student lilei = new Student("lilei","class1");
   HashMap<Student, String> hashMap = new HashMap<>();
   hashMap.put(lilei, lilei.className);
   String className = hashMap.get(new Student("lilei","class1"));//值与之前的lilei相同,即equals会为true   System.out.println(className);
}

className的值为多少呢? class1? NO!是null!!!!(诶?)

为什么呢?因为我们并没有重写hashcode,所以即使我们去get的时候传入的Student的name以及classname与put的时候的对象值是一样的,也即它们是equals(我重写了equals!),但是要注意,它们的hashcode是不一样的,这样就违反了上面所说的equals相等,hashCode也要相等的原则,所以当我们期望get到的是class1的时候,我们需要重写hashCode方法,让它们的hashcode相同!

那么问题来了,如何去重写hashCode呢?返回一个固定值?比如1?NO!!! So,how?

如何重写hashCode

EJ给出的解决办法:

  1. 把某个非零的常数值,比如17,保存在一个名为result的int类型的变量中。
  2. 对于对象中每个关键域f(指equals方法中涉及的每个域),完成以下步骤:
    • 如果f是boolean,则计算 f?1:0
    • 如果是byte,char,short或int,则计算 (int)f
    • 如果是long,则计算(int)(f^(f>>>32))
    • 如果是float,则Float.floatToIntBits(s)
    • 如果是double,则计算Double.doubleToLongBits(f),再按long类型计算一遍
    • 如果是f是个对象引用,并且该类的equals方法通过递归地调用equals的方式来比较这个域,则同样为这个域递归调用hashCode。如果需要更复杂的比较,则为这个域计算一个‘范式’,然后针对这个范式调用hashCode。如果这个域的值为null,则返回0(或者其他某个常数,但通常是0)。
    • 如果是个数组,则需要把每个元素当做单独的域来处理。也就是说,递归地应用上述规则,对每个重要的元素计算一个散列码,然后根据步骤b中的做法把这些散列值组合起来。 如果数组域中的每个元素都很重要,可以利用发行版本1.5中增加的其中一个Arrays.hashCode方法。
    • 步骤(b) 按照下面公式,把(a)步骤中计算得到的散列码c合并到result中:result = 31*result+c (为什么是31呢?)
    • 步骤(a) 为该域计算int类型的散列码c:
  3. 返回result
  4. 测试,是否符合『相等的实例是否都具有相等的散列码』

OK,知道怎么写之后,我们重写Student类的hashCode方法:

@Override
public int hashCode() {
   int result = 17;//非0 任选
   result = 31*result + name.hashCode();
   result = 31*result + className.hashCode();
   return result;
}

这下之前的代码输出的结果为class1了!!!~

为什么要选31?

因为它是个奇素数,另外它还有个很好的特性,即用移位和减法来代替乘法,可以得到更好的性能:31*i == (i<<5)-i

小结

终于学会如何写hashCode了! 老实说,我并没有做到这条要求! 因为一般来说我不会把Student这样的类当做一个Key去处理

PS:书中讲到的知识点很多,光看这个笔记是不够的,如果可以,自己去阅读书籍吧!

其他资料

dim提供:浅谈Java中的hashcode方法

第10条 始终要覆盖toString

Object类默认toString的实现方法是这样的:

    public String toString() {
       return getClass().getName() + '@' + Integer.toHexString(hashCode());
   }

它只有类名+’@’+散列值,toString的通用约定指出,被返回的字符串应该是一个『简洁的,但信息丰富,并且易于阅读的表达形式』 虽然够简单,但是信息并不丰富,而且更多时候我们更希望toString返回对象中包含的所有值得关注的信息,当属性多了,只显示信息重要的即可

toString倒没有特别大的约束

第11条 谨慎地覆盖clone

clone说到clone(protected)就必须提及一下Cloneable接口,这个接口很奇怪,没有方法:

public interface Cloneable {
}

Object的clone方法当我们尝试调用一个没有实现Cloneable接口的类的clone方法数时,clone会抛出CloneNotSupportedException,是不是很坑爹?

    protected Object clone() throws CloneNotSupportedException {
       if (!(this instanceof Cloneable)) {
           throw new CloneNotSupportedException("Class " + getClass().getName() +
                                                " doesn't implement Cloneable");
       }
       return internalClone();
   }

为什么不把clone方法放Cloneable接口里面去却偏偏塞给了Object? 这个设计我真的想不明白!!!!!

clone方法自己没怎么用过,不过可以看看其他优秀的库的设计,比如Retrofit中的OkHttpCall:

  @Override public OkHttpCall<T> clone() {
   return new OkHttpCall<>(serviceMethod, args);
 }

PS:在使用优秀的开源库的时候,如果可以,多看看它的源码,你会学到很多!相信我!

第12条 考虑实现Comparable接口

注意compareTo不是Object的方法,而是Comparable接口的方法:

public interface Comparable<T>{
   int compareTo(T t);
}

compareTo的约定跟equals类似:

PS:符合sgn(表达式)表示数学中的signum函数,它根据表达式(expression)的值为负值、零、和正直,分别返回-1、0或1

  • 确保sgn(x.compareTo(y))== -sgn(y.compareTo(x))
  • 可传递:x.compareTo(y)> 0 && y.compareTo(z) 暗示 x.compareTo(z)> 0
  • 确保x.compareTo(y)==0暗示所有z都满足sgn(x.compareTo(z))== sgn(y.compareTo(z))
  • 强烈建议(x.compareTo(y)==0),但这并非绝对重要 (个人觉得还是遵守更好一些!)

如果不想写compareTo或者类并没有实现Comparable接口的可以自定义一个Comparator类来进行比较。

需要注意,排序是不允许出现逻辑漏洞的,否则会crash!

本章完结

题外话:Object一共有12个方法,其中7个是native方法

EffectiveJava真心是本好书!!!!快去看!!!

如果对文中的链接感兴趣可以阅读原文来查看~

如果你觉得我的文章对你有帮助的话,不妨关注或分享一下,让我更有动力分享

本文分享自微信公众号 - 程序亦非猿(chengxuyifeiyuan),作者:程序亦非猿

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 第9条 覆盖equals时总要覆盖hashCode

    覆盖了equals方法,也必须覆盖hashCode方法,if not,就违反了hashCode的通用约定,会导致无法跟基于散列的集合正常运作.

    程序亦非猿
  • 【AAC 系列二】深入理解架构组件的基石:Lifecycle

    在前文,我就提到 Android Architecture Components ,是一个帮助开发者设计 健壮 、 可测试 且 可维护的一系列库的集合。

    程序亦非猿
  • 使用 VS Code 上手体验 Flutter

    Flutter 目前支持 Android Studio/Intellij/Visual Studio Code/终端&文本编辑器 四种方式来编写, AS 我已经...

    程序亦非猿
  • 用了这么久的equals,你知道还要遵守约定么

    重写equals 方法看起来很简单,但是还会有多种方式导致出错,后果可能是严重的。最简单,最容易避免出错的方式是 避免重写equals方法 ,采用这种方式的每个...

    cxuan
  • java中equals,hashcode和==的区别

    byte,short,char,int,long,float,double,boolean 他们之间的比较,应用双等号(==),比较的是他们的值。

    Anymarvel
  • Effective Java(二)

    尽管 Object 是一个具体类,但设计它主要是为了扩展。它所有的非 final 方法(equals、hashCode、toString、clone和final...

    Remember_Ray
  • JAVA-为什么equals和hashcode在重写时要保持一致

    在java中equals方法是写在Object类中的,这个方法是用来检测一个对象是否等于另一个对象。在Object类中这个方法判断两个对象是否具有相同的引用。

    用户7886150
  • equals方法的理解

    通常在面试中会被问到equals方法和==的区别,以及有没有重写过equals方法,以及重写equals方法的约定是什么? 下面简单的介绍一下我的理解: 首...

    聚沙成塔
  • Java基础提升篇:equals()方法和“==”运算符

    好好学java
  • AngularJS API之equal比较对象

    使用情况 1 首先,所有满足 a === 3 这种的对象,在angular.equals(a,b)中都会返回真 2 所有对象的类型,以及属性值都相同的,也会返回...

    用户1154259

扫码关注云+社区

领取腾讯云代金券