java - 为什么 Object.hashCode() 不遵循 Java 代码约定

Question

<分区>

Answer 1

我认为它确实遵循惯例。这完全取决于您所谈论的哪种约定。

OP 对 Code Conventions for the Java Programming Language 特别感兴趣, 方法名称的约定包含在 chapter 9 中。 .首先，应该注意的是，该文档不再维护，并包含一个重要的警告:

... the information itself may no longer be valid. The last revision to this document was made on April 20, 1999

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

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

关于hashCode()，毫无疑问是首字母小写的混合大小写。但是，OP 似乎认为它违反了方法应该是动词 的约定；隐含的假设是“哈希码”或“哈希码”是一个名词。

在判断之前，我们先看约定的第三部分:每个内部词的第一个字母[是]大写。如果您简单地假设原作者遵循这些约定，那么 hashCode() 的大写表示其作者认为“hash”和“code”是不同的词。如果你把它们分开对待，“hash”这个词在英语中是一个动词。通过这种解释，公约的所有部分都得到满足。

不可否认，术语“哈希码”已经成为(至少)Java 开发人员的常用行话，并且经常被视为名词——可能在很大程度上是因为这个方法的名称。 (鸡诉蛋？)但只有原作者才能表达他们的意图。

---

在我原来的回答中，我使用了 JavaBeans以约定为例:

A bean is a Java class with method names that follow the JavaBeans guidelines. A bean builder tool uses introspection to examine the bean class. Based on this inspection, the bean builder tool can figure out the bean's properties, methods, and events.

在 JavaBeans 中，通过“getter”方法访问属性，即通过调用 getFoo() 读取“foo”属性。但是，hashCode() 方法是 Java 语言对 Object 的所有子类强加的技术要求 但是通常不是对象表示的“业务逻辑”的属性。如果您编写一个类来表示水果，它将具有 getColor()、isSkinEdible() 等属性。如果不是 Java 的技术要求，您可能不会考虑编写类似 getHashCode() 的方法，因为...您是否找到过带有哈希码的真实活香蕉？

如果 hashCode() 被命名为 getHashCode() 那么，对于这个约定，JavaBeans 将不得不对其进行特殊处理以忽略它。或者它会始终检查该“属性”，以了解在您的程序的主要逻辑中通常用处不大的内容。

---

我无法在这个答案中涵盖所有可能的约定，但我对问题中给出的其他示例有这些想法:

• createHashCode() - 我不会使用它，即使按照惯例，因为 hashCode() 返回一个 int(a原始)并且它们不像引用类型(对象)那样创建。我认为这是错误的动词。

• toHashCode() - 对我来说，这代表一个转换。但这不是 hashCode() 所做的。如果 foo.hashCode() 返回 42 我不应该期望 42 以任何方式代表 foo .它是根据 foo 实例的信息计算得出的，但没有其他真正的相关性。许多其他实例(许多类的)可以返回 42，因此它不是其中任何一个的替代品或类似物。