問題タブ [equality]

私はに基づいてキャッシュを持っています

キーは MethodBase.GetCurrentMethod からレンダリングされます。メソッドが明示的に宣言されるまで、すべてが正常に機能しました。しかし、ある日、次のことが明らかになりました。

T がまったく異なる型を取得した場合、辞書に同じエントリを作成します。

したがって、私の質問は、ジェネリック メソッドの値をキャッシュするより良い方法についてです。(もちろん、GetCache を提供するラッパーを提供することはできますが、ジェネリック型に遭遇した場合は同等ですが、この方法はエレガントに見えません)。

ここで私が正確に欲しいものを更新してください：

java.util.Locale私があまりにも愚かなのか、それともそれを書いた人なのか疑問に思うクラスの 1 つです。マーク・デイビスはいますか？

私が見る限り、このクラスは使用されるべきではありません。クラスの内部キャッシュは非公開です。ファクトリーパッケージプライベート。文字列の比較にequals()使用します。==これは、自分でインスタンスを作成し、それらをどこかにキャッシュに入れて DRY に違反しない限り、クラスのインスタンスが等しいかどうかを比較できないことを意味します。

これは私がすべきことですか？この動作についてまともな説明はありますか???

<T>次のように、List をプロパティとして持つカスタム クラスに IEquatable を実装しています。

Equals メソッドと GetHashCode メソッドを実装しようとしているときに List が気になります。具体的には、 List <T>.Equals はその内容の等価性を評価しますか? 同様に List <T>.GetHashCode?

次のラムダ式では、Province タイプにパブリック プロパティ「byte CountryId」が含まれ、Country タイプにパブリック プロパティ「byte Id」が含まれます。

Expression は後で NHibernate Linq プロバイダーによって使用され、例外をスローしました。式変数 exp を調べたところ、等値演算子の両辺が Int32 に変換されていることがわかりました。

2 バイト値の等価演算子で、これらの値を事前に Int32 に変換する必要がある理由がわかりません。コンパイラに任せずに式を直接書きました。次の式は、NHibernate Linq プロバイダーによって適切に変換されます。

したがって、コンパイラが式を型変換して出力するのには理由があるはずです。何か案は？

エンティティはデフォルトで主キー比較による等価性を実装する必要があると思いますが、nhibernate のドキュメントではビジネス ID の使用が推奨されています。

最も明白な方法は、両方のオブジェクトの識別子の値を比較して Equals()/GetHashCode() を実装することです。値が同じである場合、両方とも同じデータベース行である必要があるため、それらは等しいです (両方が ISet に追加された場合、ISet には 1 つの要素しかありません)。残念ながら、そのアプローチを使用することはできません。NHibernate は永続的なオブジェクトにのみ識別子の値を割り当てます。新しく作成されたインスタンスには識別子の値はありません! ビジネス キーの等価性を使用して、Equals() と GetHashCode() を実装することをお勧めします。

ビジネス キーの等価性とは、Equals() メソッドがビジネス キーを形成するプロパティのみを比較することを意味します。これは、現実世界でインスタンスを識別するキー (自然な候補キー) です。

そして例（これもドキュメントから）：

ビジネス ID の概念 (例によると) は構文による比較と同じであり、これは基本的に ValueObjects に関連付けるタイプのセマンティクスであるため、これには頭が回転します。データベースの主キーを比較値として使用しない理由は、クライアント側で主キーが生成されず (インクリメンタルなど)、何らかのハッシュテーブル コレクション (ISet など) を使用する場合、オブジェクトのハッシュコードが変更されるためです。エンティティを保存するため。

equality/hashcode ( http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx ) の一般的なルールに違反せず、nhibernate ルールにも準拠する優れた等価実装を作成するにはどうすればよいですか?

私はこれを尋ねるのはかなり無知だと感じますが、なぜこれが起こっているのか誰かが私に説明することができますか？

これは、ポインターなどの優れた機能を使用している場合には理にかなっていますが、C＃を使用すると、「b」は「a」から独立したままになるという印象を受けました。

私はひどく悪い習慣を使っているだけですか？たぶん誰かが私をC＃でなぜそうなのかを説明する何かに向けることができますか？

ありがとう。

JavaScriptの比較では、どちらの演算子（== vs ===）を使用する必要がありますか？===' 'も型の同等性を保証するため、' =='は型変換を実行する可能性があることを除いて、基本的に同一であることを示します。Douglas CrockfordのJavaScript：The Good Partsでは、常に''を避けることをお勧めし==ます。しかし、2組の等式演算子を設計するという当初の考えは何だったのだろうか。

==''を使用するよりも実際に''を使用する方が適切であるという状況を見たことがあり===ますか？

Java には 2 種類の等価性があることを常に理解しています。

• value equality :.equals()メソッドを使用して、2 つのオブジェクトが null 以外のオブジェクト参照で等価関係を実装していることをテストします。
• reference equality :==演算子を使用して、2 つのプリミティブ型またはメモリ位置が等しいことをテストします。

次のページでは、これらの言語の基礎について詳しく説明します。

• Java プログラミング : Java プログラミング/オブジェクトの比較
• xyzws Java EE FAQ :等価演算子と equals メソッドの違いは何ですか?
• Java プラットフォーム API : Object.equals() の Javadoc
• Java 言語仕様 :等価演算子

nullこれらのリンクのいずれも明示的に指定していないのは、2 つのオブジェクト参照が値の等価性について比較された場合にどうなるかです。NullPointerExceptionをスローする必要があるという暗黙の前提がありますが、これはObjectUtils.equals()メソッドによって行われることではありません。これは、ベスト プラクティスのユーティリティ メソッドと見なされる可能性があります。

私が心配しているのは、Apache Commonsがバックドアによって Java に平等の第 3 の手段を効果的に導入したように見え、すでに混乱している状況がさらに複雑になった可能性があることです。値が等しいかどうかをテストしようとし、それが失敗すると参照が等しいかどうかのテストにフォールバックするため、私はこれを 3 番目の等価性の尺度と呼んでいます。Apache Commons の等価性テストは、値の等価性および参照の等価性と多くの類似点がありますが、明らかに異なります。

心配して、可能な限り使用を避けたいと思うのは正しいObjectUtils.equals()ですか?

ObjectUtils.equals()他の 2 つの平等の尺度の有用な結合を提供すると主張する議論はありますか?

選ばれた答え

この質問について意見が一致しているようには見えませんが、私は Bozho の意見を正しいとマークすることにしました。問題を隠ぺいしようとするのではなく、2 つの null オブジェクトの値が等しいかどうかを比較する根本的な原因に対処するフェイルファストコードを作成する必要があります。

2 枚のカード c1 と c4 は等しいように見えますが、そうではありません。セットで許可されるのは1つだけになるように、それらを等しくしたい。:|