7

equalsメソッドを導入する主な動機は何だと思いますjava.lang.Objectか? オーバーライドする実装のほとんどは、ドメイン中心、つまりモデル クラスです。equalsファクトリ クラスまたは同等のものでの実装はまだ見ていません。

私の結論は、これは主に Java コレクション API をサポートするために導入されたものであり、任意のObject. そうでなければ、特定のドメイン設計によって定義されたままになっている可能性があります。

PS: このスレッドがよりディスカッション指向である可能性があることは知っていますが、これについての洞察を得るための他の場所はありませんでした。私はこれに対する答えを広く検索しようとしましたが、等しいものを書くベストプラクティス==との違いについて常に議論や説明に行き着きます。equals

4

4 に答える 4

5

を入れることによりequals、Object他の多くのクラスが、equalsどのタイプのオブジェクトを扱うかを具体的に知らなくても、メソッドを使用できるようになります。たとえばHashMap、アルゴリズムの一部としてHashtable使用します。equals

それを入れる代わりにObject、メソッドを持つ別のインターフェースを持つことになりますequals（または、おそらくそれを と組み合わせることComparableができますが、ここでは詳細は重要ではありません）。しかし、Java 設計者は、デフォルトのequals実装が状況によっては役立つと考えていたのでしょう (これにより、すべてのオブジェクトがequalsメソッドを持つことが保証されます)。

于 2013-05-28T01:51:53.690 に答える
3

equalsJavaに組み込むことは、言語設計上の非常に優れた決定でした。

  • 何十年にもわたる経験により、オブジェクトのクラスが異なれば等価セマンティクスも異なることが示されています。これを表現するにはメカニズムが必要であり、多態equals的なメソッドを提供することは適切なアプローチです。
  • オブジェクト ID ( ==Java ランドで) は等価性テストの合理的なデフォルトですが、多くの場合十分ではありません: 2 つのオブジェクトが同じオブジェクトでなくても等しいと見なされることがよくあります (たとえば、同一の要素を持つ 2 つのリストを考えてください)。 )
  • equalsすべてのオブジェクトに実装されるようにオブジェクト階層 ( ) の最上位に定義しない場合Object、同等性を扱う汎用コードを記述することは困難または不可能です。
  • コア言語の一部として提供しないequalsと、ライブラリ エコシステムに何百もの異なる互換性のないバリエーションが出現することが予想されます。かわいくない！

の設計に対する私の主な批判は、equalsそれを呼び出すための有効な非 null オブジェクトがあることを前提としているということです。多くの場合は true ですが、null も確認する必要がある場合があります。その結果、equalsWithNulls通常のメソッドを呼び出す前に null チェックを考慮した静的メソッドまたは類似のメソッドを使用することがよくありますequals。

于 2013-05-28T03:40:44.787 に答える
1

私は、その意図が Java よりも前の Smalltalk の設計に従うことであり、(IIRC)#=と#hash. Gosling も VM のアイデアを気に入りましたが、厄介な C++ 構文はそのままにしました。また、当時の Java がジェネリックや多重継承 (またはトレイトやミックスイン) をサポートしていなかったため、おそらく選択されました。

.equals()個人的には、変更可能なオブジェクトでは危険だと思います。さらに、タイプ セーフではありません (文字列を他のオブジェクトと比較するときに偶発的なバグが多数発生しました)。Haskell の型クラスは正しい方法だと思いますequalが、Java にはそのようなことを行うのに十分強力な型システムがあります。

于 2013-05-28T16:34:52.203 に答える