为什么Object.hashCode（）不遵循Java代码惯例

Question

是否有任何具体原因，为什么hashCode是Object类的唯一公共方法，它不遵循Sun推荐的Java代码约定，后来由Oracle推荐？我的意思是他们可以将它命名为HashCode（）或getHashCode（）或createHashCode（）正确？

编辑： 我会谈谈Java编程语言的代码约定（oracle.com/technetwork/java/codeconvtoc-136057.html）。这些约定在甲骨文的书引用的“OCA Java SE 7中编程我学习指南（考试1Z0-803）（甲骨文出版社） - 郭利，罗伯特

在document我们可以看到如下： “方法应该是动词，与 第一个字母小写字母混合，第一个字母为 ，每个内部字大写。“

AFAIK哈希码不是动词。

Answer 1

我认为它确实遵循约定。这一切都取决于你正在谈论的公约。

OP对Code Conventions for the Java Programming Language特别感兴趣，方法名称的约定在chapter 9中涵盖。首先，应该注意的是，这个文件不再被维护，并包含一个大的警告：

......信息本身可能不再有效。最后修订这份文件被做了1999年4月20日

当然，hashCode()方法早于1999年，所以我们可以参考文件，看看是否有问题的方法违反了当时的约定。该文件指出：

方法应该是动词，在大小写混合的情况下，首字母小写，每个内部单词的首字母大写。

关于hashCode()，是没有争议的，这是大小写混合的第一个字母小写。然而，OP似乎认为它违反了公约，方法应该是动词;隐含的假设是“散列码”或“散列码”是一个名词。

作出判决之前，让我们来看看该公约的第三部分：的每个单词的第一个字母[是]资本。如果您简要地假设原作者遵循了这些惯例，那么大写字母hashCode()表示其作者认为“散列”和“代码”是单独的单词。如果分开处理它们，单词“hash”是英语动词。有了这种解释，公约的所有部分都得到满足。

不可否认，术语“散列码”已成为（至少）Java开发人员的常用术语，并且经常被当作名词 - 可能在很大程度上归因于此方法的名称。 （鸡与鸡蛋？）但是只有原作者可以对他们的意图说话。

---

在我原来的答复，我用JavaBeans约定为例：

一个bean是与遵循JavaBeans指导方法名的Java类。一个bean构建器工具使用内省来检查bean类。基于这种检查，bean构建器工具可以计算出bean的属性，方法和事件。

在JavaBeans中，通过“getter”方法访问属性，即通过调用getFoo()来读取“foo”属性。然而，的hashCode()方法是由Java语言上Object所有子类征收技术要求但不是一般的“商业逻辑”对象表示的属性。如果你写一个类来表示水果，它将具有像getColor(),isSkinEdible()等属性。如果不是对于Java的技术要求，你可能不会考虑编写像getHashCode()这样的方法，因为......你有没有发现过真正的，带有哈希码的活香蕉？

如果hashCode()被命名为getHashCode()那么对于这个约定，JavaBeans必须特殊处理以忽略它。或者它总是会检查“属性”，通常对程序的主要逻辑几乎没有用处。

---

我不能覆盖这个答案的所有可能的约定，但我对这个问题给出的其他例子，这些想法：

• createHashCode() - 我不会用这个，甚至约定，因为hashCode()返回一个int（原语），它们不是创建类似引用类型（对象）。我认为这将是错误的动词。

• toHashCode() - 对我而言，这代表了转换。但这不是hashCode()。如果foo.hashCode()返回42我不应该期望42以任何方式代表foo。它从关于foo实例的信息计算，但没有其他真正的相关性。许多其他实例（很多类的实例）可能会返回42，因此它不是它们中的任何一个的替代或类似物。

Answer 2

hashCode()方法是在有约定之前指定的。另外，这个约定用于命名Java Bean的“属性”，以便于在设计工具中将bean组合在一起，并协助其他形式的自动化。在这种情况下，您不太可能需要将哈希代码作为属性公开。事实上，因为getClass()确实遵循Java Bean命名约定，所以在许多此类工具中需要特殊情况才能将其从对象属性列表中排除。