首先,我想说明我已经知道了javadoc,java.lang.Object.hashCode()因此没有必要再次提及它.
我要问的是:为什么不java.lang.Object.hashCode()进入一个名为(可能)的单独界面Hashable？像`java.lang.Comparator'？
对我来说,hashCode()仅用于与哈希相关的数据结构中,HashMap或者HashTablea)a)未在每个应用程序中使用b)通常与极少数类型的键一起使用,例如String或Integer不与InputStream(或类似的东西).
我知道我不需要hashCode()为我的每一个类实现,但是,在某种程度上不是以牺牲性能为代价向类添加方法？特别是对于java.lang.ObjectJava中每个类的超类.
即使在JVM中进行了特殊优化以便可以忽略性能损失,我仍然认为为每个人Object提供一个根本不经常实现的行为是不明智的.根据接口隔离原则:
不应该强迫任何客户端依赖它不使用的方法.
我在网上做了一些搜索,我能找到的唯一相关页面就是这个.
第一个答案表达(部分)与我的想法相同,其他一些人试图回答这个问题,主要是说" hashCode()每个人都Object可以存储任何类型的物体HashMap",我认为这并不令人满意.
我在这里提出了我自己的解决方案,它既满足了接口隔离原则,又能够在HashMap不增加整个系统复杂性的情况下存储任何内容:
hashCode()从中移除java.lang.Object.Hashable,包含hashCode()与前者相同的合同java.lang.Object.hashCode().HashProvider带有类型参数的接口T包含provideHashCode(T t)为对象提供哈希码.(想想Comparator<T>).HashProvider<Object>被调用的实现,DefaultHashProvider它为Object使用当前实现的任何一个生成哈希码Object.hashCode().(对于Java 8,Object.hashCode()是一个本机方法,我期望DefaultHashProvider.provideHashCode() …