問題タブ [equality]

最初のテイク、クラッジソリューション、センチネルアプローチ（プログラムでセンチネル値の入力を許可しないことが不可欠です）：

プログラムでセンチネル値をブロックするのを忘れ、ユーザーが B フィールドに -2147483648 を入力し、A が null であるとします。上記のコードは true を報告し、false を報告する必要があり、true または null を報告すべきではありません。

null 許容フィールドの等価性を比較する最も簡潔な方法は何ですか? A == B は、フィールドが null 可能かどうかに関係なく、true または false のみを報告する必要があります。

他の人が次のシナリオにどのように対処するかを学びたいです。

これは宿題やいかなる種類の課題でもありません。サンプルクラスは、私の質問をよりよく説明するために作成されましたが、フィードバックが必要な実際のシナリオを反映しています。

データベースからすべてのデータを取得し、それをオブジェクトに配置します。オブジェクトは単一のレコードを表し、データベースに複数のレコードが存在する場合は、データをレコードオブジェクトのList<>に配置します。

次のクラスがあるとしましょう。

わかりやすくするために、ゲッターとセッターはクラスから省略されていることに注意してください。コード警察が私にそれらを使用していないと非難する前に、この例のためだけに省略されていることに注意してください。

データベースには、従業員用のテーブルと従業員アドレス用のテーブルがあります。

概念的には、データベーステーブルのデータを表すListオブジェクトを作成します。このオブジェクトのディープクローンを作成し、それをフロントエンドのコントロールにバインドします。次に、データベースからのデータを表す2つのオブジェクト（OrigとFinal）があります。

次に、ユーザーはレコードを作成、変更、削除することにより、「Final」オブジェクトに変更を加えます。次に、これらの変更をデータベースに永続化します。

明らかに、私たちは可能な限りエレガントになりたいと思っています。それを必要とするレコードを編集、作成、削除するだけです。

最終的には、2つのListオブジェクトを比較して、次のことができるようにします。

1. 変更をデータベースに永続化できるように、どのプロパティが変更されたかを確認します。

2. これらのレコードをデータベースから削除できるように、2番目のリスト<>に存在しなくなったプロパティ（レコード）を確認します。

3. データベースにこれらを作成できるように、新しいList<>にどのような新しいプロパティが存在するかを確認します。

誰が私たちがこれを最もよく達成できるかについてボールを転がしたいと思っています。トップレベルのプロパティだけでなく、変更を確認するためにEmployee_Addressリストにもドリルダウンする必要があることに注意してください。

私は自分自身を明確にし、提案を楽しみにしています。

エンティティと集約ルートを比較するときは、Oren Eini: Generic Entity Equalityから借りた ABC を使用します。価値のあるオブジェクトについても、私は同様に独創的でした。Jimmy Bogard の Value Object ABC: Generic Value Object Equalityを使用しました。

私の質問は次のとおりです。これらのABCを継承することを好むべきですか、それとも一般的な等値/比較子を使用して、代わりに前述の動作を構成する必要がありますか? 上記の等式の実装を再利用するつもりです。

これは、System.Object がデフォルトの Equals 実装を持っていることに帰着すると思います。これにより、言語は非常に使いやすくなりますが、興味深い難問も提供されます。Jon Skeet はここで詳しく説明します:比較方法

誰かが長所または短所を考えることができますか?

• ABC を継承する方が簡単で、すぐに使用できる演算子のオーバーロードが提供されます。
• 2 つの抽象クラスをそんなに「ドラッグ」する必要がありますか? 継承グラフがより複雑になり、カップリングが追加されます。
• DI を使用して等値プロバイダーを構成できますか?

要約すると、エンティティのカスタム等価実装を使用した経験がある人はいますか? 私の目的は、実装の選択肢をより完全に理解し、解決策を実装することです。これにより、プロジェクトの寿命が延び (エントロピーが減少し)、保守性が向上します。

object.ReferenceEqualsメソッドを使用する場合と使用する場合に余分なオーバーヘッドはあり((object)obj1 == (object)obj2)ますか?

最初のケースでは、静的メソッド呼び出しが関係し、どちらの場合もオブジェクトへの何らかの形式のキャストが関係します。

コンパイラがこれらの方法のバランスを取ったとしても、不等式はどうなるでしょうか?

と比較して...

ある時点で、!= 演算子内で、または ReferenceEquals メソッドの結果に適用されると、論理否定が発生すると思います。どう思いますか？

考慮すべき読みやすさの問題もあります。ReferenceEquals は、等値をチェックする場合により明確に見えますが、不等値の場合、!前の を見逃す可能性がobject.ReferenceEqualsあります!=が、最初のバリエーションの は見逃せません。

ここで問題を解決しようとしていますが、コードが機能しない理由がわかりません。どんな助けでも大歓迎です。編集：以下で説明する修正を行うために編集されましたが、出力の2行目にまだ余分な「15」（太字）があり、それがどこから来ているのかわかりません。

私の出力は

18662658515 5552272 15

これを行うには多くの方法がありますが、関数か何かを見逃しているように感じます。

明らかにList == Listを使用Object.Equals()して返しfalseます。

リストのすべての要素が等しく、反対側のリストの同じ場所に存在する場合、それらは等しいと見なします。私は値の型を使用していますが、正しく実装された Data オブジェクトは同じように動作するはずです (つまり、コピーされた浅いリストを探しているのではなく、内部の各オブジェクトの値が同じであることだけを探しているのです)。

検索してみましたが、同様の質問がありますが、私の質問は、すべての要素が正確な順序で等しいことです。

私は2つのリストAとB（リスト）を持っています。それらが最も安価な方法で等しいかどうかを判断する方法は？'（AマイナスB）和集合（BマイナスA）=空集合'のように書くか、それらを結合して要素の量を数えることができますが、かなり高価です。回避策はありますか？

次のような C# の Address クラスがあります。

私は平等を実装しているので、ハッシュコードをオーバーライドする必要があります。最初は EJ のハッシュコード式を使用するつもりでしたが、次のように考えました: これらはすべて文字列フィールドです。StringBuilder を使用してそれらを連結し、その文字列からハッシュ コードを返すことはできないのでしょうか?

あれは：

これの利点/欠点は何ですか? なぜ私はそれをすべきではないのですか？