[解決済み] なぜjava.lang.Objectはabstractではないのですか？重複

疑問点

重複の可能性があります。

Javaです。Objectクラスが抽象化されていない理由

なぜ、Javaの基本クラスであるObjectクラスは抽象化されていないのでしょうか？

私はこの質問を本当に本当に長い間持っていて、それは純粋に好奇心からここで質問されています、それだけです。私のコードや誰かのコードで、それが抽象的でないために壊れているものは何もありませんが、なぜそれを具体化したのか不思議に思っていました。

なぜ、この Object クラスの "instance" (およびその存在、別名 Reference) が必要なのでしょうか？1つのケースは、ロックするためにObjectのインスタンスを使用する貧弱な同期コードです（少なくとも、私はかつてこの方法で使用しました...私のミス）。

Object クラスの "インスタンス" の実用的な使用はありますか？また、そのインスタンス化は OOP にどのように適合するのでしょうか。もし、それを抽象的とマークしていたら (もちろん、そのメソッドに実装を提供した後で)、どうなっていたのでしょうか?

どのように解決するのでしょうか？

のデザイナーがいなければ java.lang.Object のデザイナーが教えてくれなければ、私たちは意見に基づいて答えを出さなければなりません。それを明らかにするのに役立つかもしれない、いくつかの質問をすることができます。

オブジェクトのメソッドのどれかが抽象的であることから利益を得るでしょうか？

いくつかのメソッドは、この恩恵を受けると主張することができます。例えば hashCode() と equals() のように、もしこの2つが両方とも抽象化されていたら、おそらくこの複雑さにまつわるフラストレーションはもっと少なかったでしょう。そうすれば、開発者はそれらをどのように実装すべきかを考えなければならず、一貫性を持たせることがより明白になります（Effective Javaを参照）。しかし、私はどちらかというと hashCode() , equals() と clone() は、別々の、オプトインの抽象化（すなわち、インターフェース）に属します。他のメソッドは wait() , notify() , finalize() などは十分に複雑であり、ネイティブであるため、すでに実装されていることが最善であり、抽象化されることによるメリットはないでしょう。

つまり、Object のメソッドのどれもが抽象化されることで利益を得ることはない、というのが答えになると思います。

Object クラスを抽象的であるとマークすることは有益でしょうか？

すべてのメソッドが実装されていると仮定すると、Object を抽象化することの唯一の効果は、構築できないことです（すなわち new Object() はコンパイルエラーになります)。これには利点があるのでしょうか？私は、quot;object" という用語自体が抽象的であるため、オブジェクト指向のパラダイムに適合するという意見を持っています（あなたの周りで、完全に object" と表現できるものを見つけられますか？しかし、これは ピュアリスト 側です。空のサブクラスであっても、任意の具象サブクラスの名前を選ぶことを開発者に強制することで、開発者の意図をよりよく表現するコードを作成できると主張することができます。私が思うに、完全に 正しい であるためには、Object には abstract をマークする必要がありますが、結局のところ、実際の利点はなく、デザインの好みの問題です（プラグマティズム対純度）。

同期のためにプレーン オブジェクトを使用する慣習は、それが具体的であるための十分な理由ですか?

他の多くの回答は、同期に使用するプレーンなオブジェクトを構築することについて話しています。 synchronized() 操作で使用するプレーン オブジェクトを構築することについて述べています。これは一般的に受け入れられている慣習かもしれませんが、設計者が抽象的であることを望んだ場合、それが Object を妨げる十分な理由になるとは思えません。他の回答者は、特定のオブジェクトを同期させたい場合は常に、Object の単一の空のサブクラスを宣言しなければならないと述べていますが、これには納得がいきません。 java.lang.Lock など）、同期を取りたいときにいつでも構築できるようになります。こうすることで、より強力な意図のステートメントを作成するという利点もあります。

Object を抽象化することによって悪影響を受ける可能性がある他の要因はありますか?

純粋なデザインの観点とは別に、この選択に影響を与えたかもしれないいくつかの領域があります。残念ながら、それらについて詳しく説明できるほどの知識はありません。しかし、これらのどれかが決断に影響を与えたとしても、私は驚きません。

• パフォーマンス
• セキュリティ
• JVMの実装の簡素化

他の理由もあるのでしょうか？

リフレクションに関連しているのではないかということが言われています。しかし、リフレクションは Object が設計された後に導入されたものです。だから、リフレクションに影響するかどうかはムダで、理由にはならない。ジェネリックについても同じです。

java.lang.Objectは人間によって設計されたという忘れがたい指摘もあります：彼らは間違いを犯したかもしれませんし、質問を考慮しなかったかもしれません。欠陥のない言語というのは存在しませんし、この は はそのひとつかもしれませんが、もしそうだとしても、それは大きなものではありません。そして、私は、野心に欠けることなく、このような広く使用されている技術、特に 15 年 (？) も続いている技術の重要な部分の設計に関与することは非常にまれであると安全に言えると思いますので、これは批判と見なされるべきではないでしょう。

とはいえ、私はそれを抽象的なものにしたでしょう;-p

概要

基本的に、私が見る限り、 "なぜ java.lang.Object は concrete なのか "、または (そうだとしたら) "なぜ java.lang.Object は abstract なのか " という両方の問いに対する答えは... "なぜいけないのか "；であると思います。