EqualsメソッドがオーバーライドされているときにGetHashCodeをオーバーライドすることが重要なのはなぜですか？

次のクラスを考える

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null) 
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Which is preferred?

        return base.GetHashCode();

        //return this.FooId.GetHashCode();
    }
}

sテーブルの行を表すEqualsため、メソッドをオーバーライドしました。オーバーライドするための好ましい方法はどれですか？FooFooGetHashCode

なぜオーバーライドすることが重要なのGetHashCodeですか？

はい、アイテムが辞書にキーとして使用されるかどうかが重要です。HashSet<T>これは、IEqualityComparer<T>アイテムをバケットにグループ化するために（カスタムがない場合）使用されるためです。2つのアイテムのハッシュコードが一致しない場合、それらは等しいと見なされない可能性があります（Equalsが呼び出されることはありません）。

GetHashCodeメソッド（）メソッドを反映すべきであるEqualsロジック。ルールは次のとおりです。

• 2つのものが等しい場合（Equals(...) == true）、それらは同じ値を返す必要がありますGetHashCode()
• GetHashCode()等しい場合、それらが同じである必要はありません。これは衝突でありEquals、真の等価かどうかを確認するために呼び出されます。

この場合、「return FooId;」が適切なGetHashCode()実装であるように見えます。複数のプロパティをテストする場合、以下のようなコードを使用してそれらを組み合わせて、対角線の衝突を減らすことが一般的です（つまり、とnew Foo(3,5)は異なるハッシュコードを持っていますnew Foo(5,3)）：

unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
    int hash = 13;
    hash = (hash * 7) + field1.GetHashCode();
    hash = (hash * 7) + field2.GetHashCode();
    ...
    return hash;
}

ああ-便宜のために、あなたはまた、提供することを検討可能性がある==と!=オーバーライドするときの演算子EqualsとGetHashCode。

これを間違えたときに何が起こるかを示すデモがここにあります。

GetHashCode()Marcがすでに述べたルールに加えて、ハッシュコードはオブジェクトの存続期間中に変更されるべきではないため、実際に正しく実装するのは非常に困難です。したがって、ハッシュコードの計算に使用されるフィールドは不変でなければなりません。

私はNHibernateを使用していたときに、最終的にこの問題の解決策を見つけました。私のアプローチは、オブジェクトのIDからハッシュコードを計算することです。IDはコンストラクターを介してのみ設定できるため、IDを変更する場合は非常にまれであり、新しいIDを持つ新しいオブジェクトを作成する必要があるため、新しいハッシュコードを作成する必要があります。IDをランダムに生成するパラメーターなしのコンストラクターを提供できるため、このアプローチはGUIDで最適に機能します。

Equalsをオーバーライドすることで、特定の型の2つのインスタンスを比較する方法をよりよく理解していることを基本的に示しているため、最高のハッシュコードを提供するための最良の候補になる可能性があります。

これは、ReSharperがGetHashCode（）関数を書き込む方法の例です。

public override int GetHashCode()
{
    unchecked
    {
        var result = 0;
        result = (result * 397) ^ m_someVar1;
        result = (result * 397) ^ m_someVar2;
        result = (result * 397) ^ m_someVar3;
        result = (result * 397) ^ m_someVar4;
        return result;
    }
}

ご覧のとおり、クラスのすべてのフィールドに基づいて適切なハッシュコードを推測しようとしていますが、オブジェクトのドメインまたは値の範囲がわかっているため、より適切なものを提供できます。

nullオーバーライドする場合は、objパラメータをチェックすることを忘れないでくださいEquals()。また、タイプを比較します。

public override bool Equals(object obj)
{
    Foo fooItem = obj as Foo;

    if (fooItem == null)
    {
       return false;
    }

    return fooItem.FooId == this.FooId;
}

この理由は、とのEquals比較時にfalseを返す必要があるためですnull。http://msdn.microsoft.com/en-us/library/bsc2ak47.aspxも参照してください。

どうですか：

public override int GetHashCode()
{
    return string.Format("{0}_{1}_{2}", prop1, prop2, prop3).GetHashCode();
}

パフォーマンスは問題ではないと仮定:)

対処すべき問題が2つあります。

1. GetHashCode()オブジェクトのフィールドを変更できる場合は、賢明な方法を提供できません。また、多くの場合、オブジェクトはに依存するコレクションでは使用されません GetHashCode()。したがって、実装のコストGetHashCode()は多くの場合それだけの価値がないか、不可能です。

2. 誰かが呼び出しGetHashCode()を行うコレクションにオブジェクトを配置 し、正しい方法で動作さEquals()せるGetHashCode()ことなく オーバーライドした場合、その人は問題の追跡に何日も費やす可能性があります。

したがって、デフォルトではそうします。

public class Foo
{
    public int FooId { get; set; }
    public string FooName { get; set; }

    public override bool Equals(object obj)
    {
        Foo fooItem = obj as Foo;

        if (fooItem == null)
        {
           return false;
        }

        return fooItem.FooId == this.FooId;
    }

    public override int GetHashCode()
    {
        // Some comment to explain if there is a real problem with providing GetHashCode() 
        // or if I just don't see a need for it for the given class
        throw new Exception("Sorry I don't know what GetHashCode should do for this class");
    }
}

これは、フレームワークが同じである2つのオブジェクトが同じハッシュコードを持つ必要があるためです。equalsメソッドをオーバーライドして2つのオブジェクトの特別な比較を行い、2つのオブジェクトがメソッドによって同じと見なされる場合、2つのオブジェクトのハッシュコードも同じである必要があります。（辞書とハッシュテーブルはこの原則に依存しています）。

上記の答えを追加するだけです：

Equalsをオーバーライドしない場合、デフォルトの動作では、オブジェクトの参照が比較されます。同じことがハッシュコードにも当てはまります-デフォルトの実装は通常、参照のメモリアドレスに基づいています。Equalsをオーバーライドしたので、正しい動作は、参照ではなくEqualsに実装したものを比較することなので、ハッシュコードについても同じようにする必要があります。

クラスのクライアントは、ハッシュコードがequalsメソッドと同様のロジックを持つことを期待します。たとえば、IEqualityComparerを使用するlinqメソッドは、最初にハッシュコードを比較し、それらが等しい場合にのみ、より高価なEquals（）メソッドを比較します。実行するには、ハッシュコードを実装しなかった場合、等しいオブジェクトはおそらく異なるハッシュコードを持ち（メモリアドレスが異なるため）、等しくないと誤って判断されます（Equals（）はヒットさえしません）。

さらに、ディクショナリでオブジェクトを使用した場合にオブジェクトを見つけられない可能性があるという問題を除いて（1つのハッシュコードによって挿入されたため、デフォルトのハッシュコードはおそらく異なるため、Equals（） Marc Gravellが彼の答えで説明しているように、呼び出されることさえありません。また、同じキーを許可しないディクショナリまたはハッシュセットの概念の違反も導入します。これらのオブジェクトは、Equalsをオーバーライドしたときに本質的に同じであるとすでに宣言しているため、一意のキーを持っていると思われるデータ構造上の異なるキーとして両方を必要とすることはありませんが、ハッシュコードが異なるため、「同じ」キーが異なるキーとして挿入されます。

ハッシュコードは、Dictionary、Hashtable、HashSetなどのハッシュベースのコレクションに使用されます。このコードの目的は、特定のオブジェクトを特定のグループ（バケット）に配置することにより、特定のオブジェクトを非常にすばやく事前に並べ替えることです。この事前ソートは、ハッシュコレクションからオブジェクトを取得する必要がある場合に、このオブジェクトを見つけるのに非常に役立ちます。コードは、オブジェクトに含まれるすべてのオブジェクトではなく、1つのバケットでオブジェクトを検索する必要があるためです。ハッシュコードの分布が良いほど（一意性が高いほど）、検索が速くなります。各オブジェクトに一意のハッシュコードがある理想的な状況では、それを見つけることはO（1）操作です。ほとんどの場合、O（1）に近づきます。

それは必ずしも重要ではありません。これは、コレクションのサイズとパフォーマンス要件、およびパフォーマンス要件がわからないライブラリでクラスが使用されるかどうかによって異なります。コレクションのサイズがそれほど大きくないことをよく知っています。完璧なハッシュコードを作成することで得られる数マイクロ秒のパフォーマンスよりも貴重な時間です。そう（コンパイラーによる迷惑な警告を取り除くために）私は単に使用します：

   public override int GetHashCode()
   {
      return base.GetHashCode();
   }

（もちろん、＃pragmaを使用して警告をオフにすることもできますが、この方法を好みます。）

もちろん、パフォーマンスを必要とする立場にいるときは、ここで他の人が述べたすべての問題が当てはまります。最も重要 -それ以外の場合、ハッシュセットまたはディクショナリからアイテムを取得するときに誤った結果が発生します。ハッシュコードは、オブジェクトのライフタイムによって変化してはなりません（より正確には、ハッシュコードが必要なときなど、ディクショナリのキー）：たとえば、Valueはpublicであり、インスタンスの存続期間中にクラスの外部で変更できるため、次のコードは誤りです。したがって、ハッシュコードのベースとして使用しないでください。

   class A
   {
      public int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //WRONG! Value is not constant during the instance's life time
      }
   }    

一方、Valueを変更できない場合は、使用しても問題ありません。

   class A
   {
      public readonly int Value;

      public override int GetHashCode()
      {
         return Value.GetHashCode(); //OK  Value is read-only and can't be changed during the instance's life time
      }
   }

Equals（）で定義されているように2つのオブジェクトが等しい場合、それらが同じハッシュコードを返すことを常に保証する必要があります。他のコメントのいくつかが述べているように、オブジェクトがHashSetやディクショナリのようなハッシュベースのコンテナーで使用されない場合、理論的にはこれは必須ではありません。ただし、常にこのルールに従うことをお勧めします。その理由は、実際にパフォーマンスを改善したり、コードのセマンティクスをより適切に伝達したりするために、コレクションをあるタイプから別のタイプに変更するのは簡単すぎるためです。

たとえば、いくつかのオブジェクトをリストに保持するとします。後で誰かが実際に、たとえばHashSetの方が検索特性が優れているため、はるかに優れた選択肢であることを実感しました。これは私たちがトラブルに巻き込まれるときです。Listは、内部的に型のデフォルトの等値比較子を使用します。これは、HashSetがGetHashCode（）を使用する場合にEqualsを意味します。2つが異なる動作をする場合、プログラムも同様です。また、そのような問題はトラブルシューティングが最も簡単ではないことを覚えておいてください。

この動作を、他のいくつかのGetHashCode（）の落とし穴とまとめて、ブログの投稿で例や説明を見つけることができます。

.NET 4.7オーバーライドの好ましい方法として、GetHashCode()以下に示します。古い.NETバージョンを対象とする場合は、System.ValueTuple nugetパッケージを含めます。

// C# 7.0+
public override int GetHashCode() => (FooId, FooName).GetHashCode();

パフォーマンスの点では、この方法はほとんどの複合ハッシュコード実装よりも優れています。ValueTupleがあるstructので、任意のゴミがないだろう、と根本的なアルゴリズムは、早くそれを取得としてあります。

元のGetHashCode（）がオブジェクトのメモリアドレスを返すことは私の理解です。そのため、2つの異なるオブジェクトを比較する場合は、それをオーバーライドすることが不可欠です。

編集：これは正しくありませんでした。元のGetHashCode（）メソッドは2つの値が等しいことを保証できません。ただし、等しいオブジェクトは同じハッシュコードを返します。

以下では、リフレクションを使用する方が、プロパティの追加/削除について心配する必要がないので、パブリックプロパティを考慮したより良いオプションのように思えます（それほど一般的なシナリオではありません）。これもパフォーマンスが優れていることがわかりました（ダイアゴニスティックスストップウォッチを使用した場合との比較）。

    public int getHashCode()
    {
        PropertyInfo[] theProperties = this.GetType().GetProperties();
        int hash = 31;
        foreach (PropertyInfo info in theProperties)
        {
            if (info != null)
            {
                var value = info.GetValue(this,null);
                if(value != null)
                unchecked
                {
                    hash = 29 * hash ^ value.GetHashCode();
                }
            }
        }
        return hash;  
    }