java抽象的东西具体化,为什么java.lang.Object不是抽象的？

小编典典

如果没有设计师java.lang.Object告诉我们，我们就必须以意见为基础。有一些问题可以帮助您解决。

对象的任何方法都会从抽象中受益吗？

可以说某些方法将从中受益。以hashCode()和equals()举例来说，有可能早就少了很多挫折围绕这两个的复杂性，如果他们俩都已经取得抽象。这将要求开发人员弄清楚他们应该如何实现它们，从而使它们更加一致(请参见Effective

Java)更加明显。不过，我更认为hashCode()，equals()和clone()属于在不同的，选择在抽象(即接口)。其他方法，wait()，notify()，finalize()，等充分复杂和/或原产，所以最好他们已经实施，并不会被抽象受益。

因此，我猜答案是否定的，Object的任何方法都不会从抽象中受益。

将Object类标记为抽象是否有好处？

假设所有方法都已实现，则标记对象抽象的唯一效果是无法构造它(即，new

Object()是编译错误)。这会有好处吗？我认为“对象”一词本身就是抽象的(可以在您周围找到可以完全描述为“对象”的任何东西吗？)，因此它符合面向对象的范式。但是，它在

纯粹主义者 方面。可以说，强迫开发人员为任何具体的子类选择一个名称，即使是空的子类，也会导致代码更好地表达其意图。我认为，就范式而言，要完全 正确

，应该对对象进行标记abstract，但是当涉及到它时，并没有真正的好处，这是设计偏好的问题(实用主义vs.

使用纯对象进行同步的做法是否足以使其具体化？

其他许多答案都谈到了构造要在synchronized()操作中使用的普通对象。尽管这可能是一种普遍接受的做法，但我认为如果设计人员希望它成为防止Object抽象的足够理由，那么这还不是足够的理由。其他答案已经提到，我们想在某个对象上进行同步时，每次都必须声明一个单一的空子类，但这并不能成立-

SDK(java.lang.Lock或其他东西)中可能提供了一个空子类，可以在我们想要同步的任何时间构造它。这样做将具有创建更强有力的意图陈述的额外好处。

还有其他可能会因抽象对象而受到不利影响的因素吗？

从纯粹的设计观点来看，有几个领域可能会影响选择。不幸的是，我对它们还不够了解，无法扩展它们。但是，如果有任何一项对决定有影响，我不会感到惊讶：

性能

安全

JVM实现的简单性

可能还有其他原因吗？

有人提到它可能与反射有关。但是，反射是在对象设计之后引入的。因此，不管它是否影响反射都没有意义-这不是原因。泛型相同。

还有一个让人难忘的一点，那就是java.lang.Object是人为设计的：他们可能犯了一个错误，他们可能没有考虑过这个问题。没有没有缺陷的语言，这

可能

是其中之一，但是如果存在缺陷，那简直不是什么大问题。而且我想我可以毫无保留地说，可以放心地说，我不太可能参与设计这种广泛使用的技术的关键部分，尤其是持续了15(？)年并且仍在不断发展的强大技术，因此不应被视为批评。

话虽如此，我会把它抽象化； -p

总结

就我所知，基本上，这两个问题的答案都是“为什么java.lang.Object是具体的？”

或(如果是如此)“为什么java.lang.Object是抽象的？” 是……“为什么不呢？”。

2020-09-16