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

问题描述

可能的重复:
Java:对象类未声明为抽象的基本原理

为什么 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 类的实例"(而不是它的存在，也就是引用)?一种情况是糟糕的同步代码，它使用对象的实例进行锁定(至少我曾经这样使用过一次......我的错).

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() 和 equals() 为例，如果它们都被抽象化，那么围绕这两者的复杂性可能会少很多挫败感.这将要求开发人员弄清楚他们应该如何实现它们，使它们应该保持一致更加明显(参见 Effective Java).但是，我更倾向于认为 hashCode()、equals() 和 clone() 属于单独的、可选的抽象(即接口).其他方法，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()是编译错误).这会有好处吗?我认为术语对象"本身是抽象的(你能在你周围找到任何可以完全描述为对象"的东西吗?)，所以它适合面向对象的范式.然而，它站在纯粹主义一边.有人可能会争辩说，强迫开发人员为任何具体的子类选择一个名称，即使是空的，也会导致代码更好地表达他们的意图.我认为，就范式而言，要完全正确，应该将 Object 标记为 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 抽象的充分理由.其他答案提到了我们在任何时候想要在某个对象上同步时都必须声明一个空的 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.

是否有任何其他因素可能因将 Object 抽象化而受到不利影响?

从纯设计的角度来看，有几个方面可能会影响选择.不幸的是，我对它们的了解还不够深入.但是，如果其中任何一个对决定产生影响，我也不会感到惊讶:

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屋！