我偶然发现abstract AbstractUnit of the uom-se project声明了
// //////////////////////////////////////////////////////////////
// Ensures that sub-classes implements hashCode/equals method.
// //////////////////////////////////////////////////////////////
@Override
public abstract int hashCode();
@Override
public abstract boolean equals(Object that);
框架需要hashCode和equals在内部检查相等性，然后实现应该在框架本身完成，或者由用户来决定是否覆盖这些方法。后一种情况，无论如何，必须为任何 Java类做出此决定，因为它在Object中的实现方式以及Java和一般编程中的标识和相等比较意味着什么。那么宣言的目的是什么呢？
这有点像反模式，因为对于那些知道自己正在做什么的程序员来说，声明是不必要的，并且引诱那些不使用super.equals/hashCode覆盖它的人或者创建他们不需要的实现或者想要。
答案 0 :(得分：1)
你说过：
后一种情况无论如何都必须为任何Java类做出决定......
确实需要完成它，但没有这些声明，没有任何东西强迫AbstractUnit的子类的作者实际执行它，因为Object上有默认实现。因此，声明的目的是强制子类的作者根据其子类实现hashCode和equals，而不是将它们排除在外。这至少消除了子类作者甚至没有想到需要这样做的错误的常见原因。 （遗憾的是，它可以消除导致错误的第二个常见原因：作者这样做不正确。）
重新编辑：
这闻起来像一个反模式......
它是否是一种反模式是一个意见问题，因此也是SO的主题。
...因为对于那些知道他们正在做什么的程序员来说，声明是不必要的......
很多作者不明白需要以兼容的方式覆盖equals和hashCode 非常 -established。
...并引诱那些不会用
super.equals/hashCode覆盖它的人
他们不能。 super的版本为abstract。
...或创建他们不需要或不想要的实现。
显然，如果他们正在撰写AbstractUnit的子句子，他们做需要实施equals和hashCode; AbstractUnit的作者明显已确定A）Object中的版本无法正常使用AbtractUnit的逻辑，而B）他们无法提供合理的默认。所以他们强迫子类作者以他们唯一的方式实现它们：通过声明它们abstract。