今天的软件构造已经复习完了ADT和OOP的等价性。
其中个人认为比较重点的是equals和hashcode的重写。
equals和hashcode的关系如下:
两个对象相等,hashcode一定相等
两个对象不等,hashcode不一定不等
hashcode相等,两个对象不一定相等
hashcode不等,两个对象一定不等
对于equals的重写是因为Object中的equals默认是按==来进行判断相等的,也即判断引用或者内存地址是否相同,这使得如果我们判断相等的标准与其产生冲突后,一定要对其进行@Override.
而hashcode的重写是因为必须保证两个等价的对象的hashcode必须相同,默认的hashcode仍是以对象所在的内存地址来进行返回hashcode,这样就需要对其进行重写。
如果只重写了equals方法而没有重写hashCode方法的话,则会违反约定:相等的对象必须具有相等的hashCode, 同时对于HashSet和HashMap这些基于散列值实现的类也会有问题。HashMap的底层处理机制是以数组的方法保存放入的数据的(Node<K,V>[] table),其中的关键是数组下标的处理 数组的下标是根据传入的元素hashCode方法的返回值再和特定的值异或决定的。如果该数组位置上已经有放入的值了,且传入的键值相等则不处理,若不相等则覆盖原来的值,如果数组位置没有条目,则插入,并加入到相应的链表中。检查键是否存在也是根据hashCode值来确定的。所以如果不重写hashCode的话可能导致HashSet、HashMap不能正常的运作。
如果我们将某个自定义对象存到HashMap或者HashSet及其类似实现类中的时候,如果该对象的属性参与了hashCode的计算,那么就不能修改该对象参数hashCode计算的属性了有可能会移除不了元素,导致内存泄漏。
所以能够得到如下结论:
明天继续复习,可能还会更新。