为什么java.lang.Object不是抽象的？ [英] Why java.lang.Object is not abstract?

问题描述

可能重复：

Java：Object类的基本原理未被声明为抽象

为什么Object类是基于Java的基类，而不是抽象的？

Why is the Object class, which is base class of 'em all in Java, not abstract?

我有过这个问题真的很长一段时间，这里纯粹是出于好奇而被问到这一点。我的代码或任何人的代码都没有破坏，因为它不是抽象的，但我想知道为什么他们具体化了？

I've had this question for a really really long time and it is asked here purely out of curiosity, that's all. Nothing in my code or anybody's code is breaking because it is not abstract, but I was wondering why they made it concrete?

为什么有人想要一个实例（和这个Object类没有它的存在（参考）？一个案例是一个糟糕的同步代码，它使用一个Object的实例来锁定（至少我用这种方式一次......我的坏）。

Why would anyone want an "instance" (and not its presence a.k.a. Reference) of this Object class? One case is a poor synchronization code which uses the instance of an Object for locking (at least I used it this way once.. my bad).

有没有实用的使用Object类的实例？它的实例化如何适合OOP？如果他们将其标记为抽象（当然在为其方法提供实现之后）会发生什么？

Is there any practical use of an "instance" of an Object class? And how does its instantiation fit in OOP? What would have happened if they had marked it abstract (of course after providing implementations to its methods)?

推荐答案

没有设计师 java.lang.Object 告诉我们，我们必须根据意见作出答案。有几个问题可以提出来帮助清除它。

Without the designers of java.lang.Object telling us, we have to base our answers on opinion. There's a few questions which can be asked which may help clear it up.

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

可以说有些方法会从中受益。拿 hashCode（）和等于（）例如，对于复杂性的复杂性，可能会有很少的挫败感。这两个如果他们都被抽象了。这将要求开发人员弄清楚他们应该如何实现它们，使它们更加明显，它们应该是一致的（参见Effective Java）。但是，我更认为 hashCode（），等于（）和 clone（）属于单独的opt-in抽象（即接口）。其他方法， wait（）， notify（）， finalize（）等等是足够复杂和/或原生的，所以最好它们已经实现，并且不会从抽象中受益。

It could be argued that some of the methods would benefit from this. Take hashCode() and equals() for instance, there would probably have been a lot less frustration around the complexities of these two if they had both been made abstract. This would require developers to figure out how they should be implementing them, making it more obvious that they should be consistent (see Effective Java). However, I'm more of the opinion that hashCode(), equals() and clone() belong on separate, opt-in abstractions (i.e. interfaces). The other methods, wait(), notify(), finalize(), etc. are sufficiently complicated and/or are native, so it's best they're already implemented, and would not benefit from being abstracted.

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

So I'd guess the answer would be no, none of the methods of Object would benefit from being abstract.

将Object类标记为是一个好处抽象？

假设所有方法都已实现，标记Object abstract的唯一效果是它无法构造（即 new Object（）是编译错误）。这会有好处吗？我认为术语对象本身就是抽象的（你能找到任何可以完全描述为对象的东西吗？），所以它适合面向对象的范式。但是，它位于 purist 方面。可以说，强制开发人员为任何具体的子类选择一个名称，即使是空子类，也会产生更好地表达其意图的代码。我认为，就范式而言，要完全正确，对象应该标记为 abstract ，但是当它归结为它时，就没有真正的好处，这是设计偏好（实用主义与纯度）的问题。

Assuming all the methods are implemented, the only effect of marking Object abstract is that it cannot be constructed (i.e. new Object() is a compile error). Would this have a benefit? I'm of the opinion that the term "object" is itself abstract (can you find anything around you which can be totally described as "an object"?), so it would fit with the object-oriented paradigm. It is however, on the purist side. It could be argued that forcing developers to pick a name for any concrete subclass, even empty ones, will result in code which better expresses their intent. I think, to be totally correct in terms of the paradigm, Object should be marked abstract, but when it comes down to it, there's no real benefit, it's a matter of design preference (pragmatism vs. purity).

使用普通对象进行同步的做法有足够的理由使其具体化吗？

许多其他答案都讨论构建一个在 synchronized（）操作中使用的普通对象。虽然这可能是一种常见且被接受的做法，但我不认为如果设计师希望将对象抽象化，那将是一个足够好的理由。其他答案已经提到我们如何在我们想要在某个对象上同步时声明Object的单个空子类，但是这并不是站起来的 - SDK中可以提供一个空子类（ java.lang.Lock 或其他），可以在我们想要同步时构建。这样做会带来额外的好处，即创建更强烈的意图声明。

Many of the other answers talk about constructing a plain object to use in the synchronized() operation. While this may have been a common and accepted practice, I don't believe it would be a good enough reason to prevent Object being abstract if the designers wanted it to be. Other answers have mentioned how we would have to declare a single, empty subclass of Object any time we wanted to synchronise on a certain object, but this doesn't stand up - an empty subclass could have been provided in the SDK (java.lang.Lock or whatever), which could be constructed any time we wanted to synchronise. Doing this would have the added benefit of creating a stronger statement of intent.

是否有任何其他因素可能会因为对象抽象而受到不利影响？

有几个区域，与纯粹的设计观点分开，可能影响了选择。不幸的是，我对他们的了解并不充分。但是，如果其中任何一项对决定产生影响，我不会感到惊讶：

There are several areas, separate from a pure design standpoint, which may have influenced the choice. Unfortunately, I do not know enough about them to expand on them. However, it would not suprise me if any of these had an impact on the decision:

• 表现


• 安全性


• JVM的简单实施

还有其他吗？理由？

有人提到它可能与反思有关。但是，在设计Object之后引入了反射。因此，它是否影响反射是没有实际意义的 - 这不是原因。对于泛型也是如此。

It's been mentioned that it may be in relation to reflection. However, reflection was introduced after Object was designed. So whether it affects reflection or not is moot - it's not the reason. The same for generics.

java.lang.Object也是人类设计的难忘点：他们可能犯了一个错误，他们可能没有考虑过这个问题。没有没有缺陷的语言，这个可能就是其中之一，但如果是的话，它就不是一个大的。而且我认为我可以肯定地说，在不缺乏野心的情况下，我不太可能参与设计这种广泛使用的技术的关键部分，特别是那个持续15年（？）并仍然强劲的技术，所以这个不应该被视为批评。

There's also the unforgettable point that java.lang.Object was designed by humans: they may have made a mistake, they may not have considered the question. There is no language without flaws, and this may be one of them, but if it is, it's hardly a big one. And I think I can safely say, without lack of ambition, that I'm very unlikely to be involved in designing a key part of such a widely used technology, especially one that's lasted 15(?) years and still going strong, so this shouldn't be considered a criticism.

话虽如此，我本来是抽象的;-p

Having said that, I would have made it abstract ;-p

摘要

基本上，据我所知，这两个问题的答案为什么java.lang.Object具体？或者（如果是这样）为什么java.lang.Object是抽象的？是......为什么不呢？

Summary
Basically, as far as I see it, the answer to both questions "Why is java.lang.Object concrete?" or (if it were so) "Why is java.lang.Object abstract?" is... "Why not?".

这篇关于为什么java.lang.Object不是抽象的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！