21

java.lang.Objectクラスがabstractであると宣言されなかったのはなぜですか?

確かに、オブジェクトが有用であるためには、追加された状態または動作が必要です。オブジェクト クラスは抽象化であり、そのため、抽象として宣言されている必要があります... なぜそうしないことを選択したのですか?

4

10 に答える 10

17

固有のObject状態や動作がない場合でも、 は役に立ちます。

1 つの例は、同期に使用される汎用ガードとしての使用です。

public class Example {
    private final Object o = new Object();

    public void doSomething() {
        synchronized (o) {
            // do possibly dangerous stuff
        }
    }
}

このクラスの実装は少し単純ですが (ここでは、明示的なオブジェクトを使用すると便利な理由は明らかではありません。メソッドを宣言するだけでもかまいません)、これが実際に役立つsynchronizedケースがいくつかあります。

于 2009-04-02T16:01:26.450 に答える
14

アンデ、あなたはこれに近づいていると思います-しゃれは意図されていません-不必要な程度の抽象化で。この（IMHO）不必要なレベルの抽象化が、ここで「問題」を引き起こしていると思います。あなたはおそらく数学的理論的アプローチからこれに取り組んでいますが、私たちの多くは「問題を解決しようとしているプログラマー」のアプローチからこれに取り組んでいます。このアプローチの違いが意見の相違を引き起こしていると思います。

プログラマーが実用性と実際に何かを実装する方法を検討するとき、実際のインスタンスがまったく無関係な完全に任意のオブジェクトが必要になることが何度もあります。null にすることはできません。私が別の投稿へのコメントで示した例は、*Set( *==HashまたはConcurrentor または選択の種類) の実装であり、これは通常、バッキング*Mapを使用し、Mapキーを Set として使用することによって行われます。nullを値として使用できないことが多いMapため、一般的に行われているのは、静的Objectインスタンスを値として使用することです。これは無視され、使用されることはありません。ただし、null 以外のプレースホルダーが必要です。

もう 1 つの一般的な使用法は、いくつかsynchronizedの同期が必要なキーワードであり、異なるクラスが同じロックで意図せずに同期するデッドロックを回避するために、同期アイテムを完全にプライベートにする必要があります。非常に一般的なイディオムは、クラスで使用する a をロックとして割り当てることです。公平を期すために、Java 5および関連する追加機能の時点で、このイディオムはあまり適用されません。 Objectprivate final Objectjava.util.concurrent.locks.Lock

Object歴史的に、Java ではインスタンス化可能であることが非常に便利でした。設計を少し変更したり、API を少し変更したりすれば、これは不要になるということをうまく指摘できます。あなたはおそらくこれで正しいです。

はい、API は、上記の目的でプレースホルダーとして使用するために、何も追加せずにPlaceholder拡張するクラスを提供できたはずです。Objectしかし、拡張するだけで何も追加しない場合、抽象化Objectを許可する以外にクラスの価値は何ですか? Object数学的に、理論的には、おそらく値を見つけることができますが、実用的には、これを行うことでどのような価値が追加されるでしょうか?

プログラミングでは、オブジェクト、何らかのオブジェクト、 null ではない==具体的なオブジェクト、 and/orを介して比較できるものが.equals()必要な場合がありますが、このオブジェクトに他の機能は必要ありません。一意の識別子として機能するためだけに存在し、それ以外はまったく何もしません。 Objectこの役割を完全に満たし、（IMHO）非常にきれいに満たしています。

これObjectが、が抽象宣言されなかった理由の一部であると推測できます。

于 2009-04-03T19:47:54.620 に答える
4

Object は、それを拡張するクラスが有用であるために実装しなければならないメソッドを指定していますか? いいえ、したがって抽象的である必要はありません。

クラスが抽象的であるという概念には、明確に定義された意味があり、オブジェクトには適用されません。

于 2009-04-02T16:01:50.867 に答える
3

Object同期ロックをインスタンス化できます。

Object lock = new Object();

void someMethod() {
  //safe stuff
  synchronized(lock) {
     //some code avoiding race condition
  }
}

void someOtherMethod() {
  //safe code
  synchronized(lock) {
    //some other stuff avoiding race condition
  }
}
于 2009-04-02T16:11:24.587 に答える
2

Object は null よりも攻撃的ですか?

それは良い場所マーカーになります（とにかくヌルと同じくらい良いです）。

また、必要な抽象メソッドなしでオブジェクトを抽象化するのは良い設計ではないと思います。

null がスライスパン以来最高のものだと言っているわけではありません。先日、null の概念を持つことのコストと価値について議論している「発明者」の記事を読みました... (null が発明可能! どこかでゼロを発明したと主張する人がいると思います..) オブジェクトをインスタンス化できることは、null を渡すことができることよりも悪いことではありません。

于 2009-04-02T16:48:17.820 に答える
2

これが理由かどうかはわかりませんが、オブジェクトをロックとして使用できるようにします (または、より良い方法があるため、許可されます)。

Object lock = new Object();

....


synchronized(lock)
{
}
于 2009-04-02T16:02:27.837 に答える
1

単純なオブジェクトをいつプレースホルダーとして使用する必要があるかはわかりません。これは、数値システムにゼロがあるようなものと考えてください (null はデータの不在を表すため、null はこれには機能しません)。

于 2009-04-02T16:05:52.417 に答える
0

クラスを抽象化する理由があるはずです。1つは、クライアントがクラスをインスタンス化するのを防ぎ、（何らかの理由で）サブクラスのみを使用するように強制することです。もう1つは、サブクラスが実装する必要のある抽象メソッドを提供することにより、インターフェースとして使用する場合です。おそらく、Javaの設計者はそのような理由を見なかったので、java.lang.Object具体的なままです。

于 2013-02-07T03:37:24.397 に答える
0

いつものように、Guava が助けに来ます : http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Optional.htmlコードからの「null 以外のプレースホルダー」。

ここには完全に分離された質問があります：

  • なぜ彼らは Object を抽象化しなかったのですか?
  • 将来のリリースで抽象化することを決定した場合、どれだけの災害が発生しますか?
于 2013-07-03T13:36:34.133 に答える