所有属性都应该影响 JavaBean 的 hashcode() 和 equals() 方法吗？答案

【问题标题】：Should all properties necessarily influence a JavaBean's hashcode() and equals() method?所有属性都应该影响 JavaBean 的 hashcode() 和 equals() 方法吗？
【发布时间】：2019-09-19 18:05:24
【问题描述】：

要使一个类成为有效的 Javabean（根据 JavaBeans Specification），是否应该在其 equals() 方法中测试其所有属性 - 并相应地影响其 hascode() 实现？或者某些属性可能被故意搁置一旁？

例如，Person 类：

id 和 name 在 geter 和 setter 中公开的属性
无参数构造函数
仅考虑 id 的 equals 和 hashcode 方法

是否有资格成为有效的 JavaBean？

【问题讨论】：

当然，equals 和 hashcode 的一般合同允许忽略字段。我不认为 JavaBeans 规范会有所不同。
是的，这将是一个有效的 bean。事实上，这通常是应该的。 equals 和 hashCode 应该基于对象的概念标识。 bean 的每个属性的基本标识很少是正确的。

标签： java javabeans equals hashcode specifications

【解决方案1】：

与其他 Java 规范不同，Java Beans 规范相当模糊。这个想法是 bean 封装了一些专注于 GUI 的可重用功能。在本规范制定时，有一个想法是开发人员销售单独的组件，例如一些 GUI 元素。

Java Bean 是可重用的可操作软件组件在构建器工具中直观地显示。

规范将 Java bean 与“普通”Java 库区分开来：

并非所有有用的软件模块都必须变成 bean。 Bean 适用于可以可视化的软件组件操纵和定制以达到某种效果。类库是提供有用的功能的适当方式程序员，但不会从 visual 操作中受益。

规范没有为hashCode() 和equals() 定义任何要求。实施或不实施它们取决于您。对构造函数也没有要求。

如果您的类为 GUI 提供了一些可重用的功能，您可以将其称为 Java Bean。如果您的类不在 GUI 中绘制任何元素，也不对 GUI 事件做出反应，那么它就不是本规范意义上的 Java bean。但是，嘿，您多久会看到使用 Java 实现 GUI 的应用程序？ :)

许多开发人员称 Java bean 为仅满足本规范中一些要求的任何类，主要在第 8.1、8.2、8.3、8.6 节中定义，而忽略任何其他要求，例如关于侦听器和事件。从这个意义上说，您的类是一个 Java bean。

转为 hashCode() 和 equals()： 您可以使用hashCode() 和equals() 中的一些属性。这取决于用例。例如，您的班级有 4 个属性：ID、名字、姓氏和最喜欢的饮料。在一个用例中，您可能只需要通过名称来区分对象实例。然后你会在hashCode() 和equals() 中只使用名字和姓氏，而忽略 ID 和最喜欢的饮料。在其他一些用例中，您可能会将此类视为将饮料分配给人员，并且您不仅需要在hashCode() 和equals() 中包含名字和姓氏，还需要包含最喜欢的饮料。在其他一些用例中，您可能有一个约束，即每个属性组合都是唯一的，并且为了区分实例，使用 ID 就足够了，因此您在hashCode() 和equals() 中只有一个属性 ID。根据您的目标，您可以以不同的方式实施这些方法。

【讨论】：

我总体上喜欢您的回答，但我认为您误解了“可以在视觉上操纵”部分。您可以在可视化编辑器中设置属性的事实（这是标准命名的原因 - 可视化编辑器必须能够发现它们）并不意味着 bean 本身就是 gui 元素。如果你眯着眼睛，你可以想象在可视化编辑器中连接任何其他类型的应用程序。
1) 并不暗示 bean 本身就是 gui 元素 - 正确。我没有说它是。我说如下：如果你的类为 GUI 提供了一些可重用的功能。它不必是按钮或表格。例如，它可以是控制器。但在我看来（可能我错了）整个规范都是围绕 GUI 隐式构建的。它明确地将 Java bean 与“普通”库分开。 2）您对属性编辑器和属性发现是正确的。但是，当我们有一个对象可以长时间使用并可以与其他对象区分开来时？主要在 GUI 中。
我想我们现在同意了
未来的读者可能也有兴趣，What is the difference between a JavaBean and a POJO?