这是语言设计中的另一个问题，在你开始挖掘并且意识到这实际上是一个坏主意之前，这似乎是“显然是个好主意”。
这封邮件涉及很多主题（以及其他主题。）有多种设计力量融合在一起，使我们进入了当前的设计：
- 保持继承模型简单的愿望；
- 一旦你查看了明显的示例（例如，
AbstractList
变成一个接口），便意识到继承equals / hashCode / toString与单继承和状态紧密相关，并且接口被多重继承且为无状态。 - 它可能为某些令人惊讶的行为打开了大门。
你已经达到了“保持简单”的目标。继承和冲突解决规则的设计非常简单（类胜于接口，派生接口胜于超接口，其他任何冲突都由实现类解决。）当然，可以对这些规则进行调整以使其成为异常，但是我想你会发现，当你开始使用该字符串时，增量复杂性并没有你想象的那么小。
当然，有一定程度的好处可以证明更加复杂，但是这种情况并不存在。我们在这里讨论的方法是equals，hashCode和toString。这些方法本质上都是关于对象状态的，并且拥有状态而不是接口的类是确定状态对该类意味着什么的最佳位置（特别是当平等的契约非常牢固时；请参见有效）。 Java带来一些令人惊讶的后果）；接口编写器距离太远了。
AbstractList举个例子很容易。如果我们可以摆脱该问题
AbstractList并将其放入List界面中，那将是很可爱的。但是，一旦你超越了这个显而易见的示例，就找不到很多其他好的示例。从根本上说，
AbstractList它是为单一继承而设计的。但是接口必须设计用于多重继承。
进一步，假设你正在编写此类：
class Foo implements com.libraryA.Bar, com.libraryB.Moo { // Implementation of Foo, that does NOT override equals}该Foo作家着眼于超类型，认为没有实现平等的，并得出结论，得到参考平等，所有他所要做的就是继承平等Object。然后，下周，“有帮助”的Bar库维护者添加了默认equals实现。哎呀！现在，的语义Foo已被另一个维护域中的接口“有帮助地”破坏了，为通用方法添加了默认值。
默认值应该是默认值。向没有接口（层次结构中的任何地方）的接口添加默认值不应影响具体实现类的语义。但是如果默认值可以“覆盖” Object方法，那将不是事实。
因此，尽管它看起来像是一种无害的功能，但实际上却是相当有害的：它增加了很多复杂性，几乎没有增量表达能力，而且对于原本意图良好，无害的更改进行单独编译的界面，破坏太容易了。实现类的预期语义。
