GetHashCode переопределяет объект, содержащий общий массив

Из-за проблем, поднятых в этой теме, я публикую еще один ответ, показывающий, что произойдет, если вы ошибетесь... в основном, что вы не можете использовать массив GetHashCode(); правильное поведение заключается в том, что при запуске предупреждения не печатаются... переключите комментарии, чтобы исправить это:

using System;
using System.Collections.Generic;
using System.Linq;
static class Program
{
    static void Main()
    {
        // first and second are logically equivalent
        SimpleTableRow<int> first = new SimpleTableRow<int>(1, 2, 3, 4, 5, 6),
            second = new SimpleTableRow<int>(1, 2, 3, 4, 5, 6);

        if (first.Equals(second) && first.GetHashCode() != second.GetHashCode())
        { // proven Equals, but GetHashCode() disagrees
            Console.WriteLine("We have a problem");
        }
        HashSet<SimpleTableRow<int>> set = new HashSet<SimpleTableRow<int>>();
        set.Add(first);
        set.Add(second);
        // which confuses anything that uses hash algorithms
        if (set.Count != 1) Console.WriteLine("Yup, very bad indeed");
    }
}
class SimpleTableRow<T> : IEquatable<SimpleTableRow<T>>
{

    public SimpleTableRow(int id, params T[] values) {
        this.Id = id;
        this.Values = values;
    }
    public int Id { get; private set; }
    public T[] Values { get; private set; }

    public override int GetHashCode() // wrong
    {
        return Id.GetHashCode() ^ Values.GetHashCode();
    }
    /*
    public override int GetHashCode() // right
    {
        int hash = Id;
        if (Values != null)
        {
            hash = (hash * 17) + Values.Length;
            foreach (T t in Values)
            {
                hash *= 17;
                if (t != null) hash = hash + t.GetHashCode();
            }
        }
        return hash;
    }
    */
    public override bool Equals(object obj)
    {
        return Equals(obj as SimpleTableRow<T>);
    }
    public bool Equals(SimpleTableRow<T> other)
    {
        // Check for null
        if (ReferenceEquals(other, null))
            return false;

        // Check for same reference
        if (ReferenceEquals(this, other))
            return true;

        // Check for same Id and same Values
        return Id == other.Id && Values.SequenceEqual(other.Values);
    }
}

FWIW, очень опасно использовать содержимое Values ​​в вашем хеш-коде. Вы должны делать это только в том случае, если вы можете гарантировать, что это никогда не изменится. Однако, поскольку он разоблачен, я не думаю, что это возможно. Хэш-код объекта никогда не должен меняться. В противном случае он теряет свое значение в качестве ключа в хеш-таблице или словаре. Рассмотрим трудно обнаруживаемую ошибку использования объекта в качестве ключа в Hashtable, его хэш-код меняется из-за внешнего воздействия, и вы больше не можете найти его в Hashtable!

Поскольку hashCode является своего рода ключом для хранения объекта (как в хеш-таблице), я бы использовал только Id.GetHashCode()

Как насчет чего-то вроде:

    public override int GetHashCode()
    {
        int hash = Id;
        if (Values != null)
        {
            hash = (hash * 17) + Values.Length;
            foreach (T t in Values)
            {
                hash *= 17;
                if (t != null) hash = hash + t.GetHashCode();
            }
        }
        return hash;
    }

Это должно быть совместимо с SequenceEqual, а не выполнять сравнение ссылок в массиве.

Мне просто пришлось добавить еще один ответ, потому что не было упомянуто одно из наиболее очевидных (и самых простых в реализации) решений - не включать коллекцию в ваш расчет GetHashCode!

Главное, что тут как будто забыли, это то, что уникальность от результата GetHashCode не требуется (а во многих случаях даже возможна). Неравные объекты не должны возвращать неравные хэш-коды, единственное требование состоит в том, чтобы одинаковые объекты возвращали одинаковые хэш-коды. Таким образом, по этому определению следующая реализация GetHashCode верна для всех объектов (при условии, что существует правильная реализация Equals):

public override int GetHashCode() 
{ 
    return 42; 
} 

Конечно, это приведет к наихудшей возможной производительности при поиске по хеш-таблице, O(n) вместо O(1), но функционально это все еще корректно.

Имея это в виду, моя общая рекомендация при реализации GetHashCode для объекта, который имеет какую-либо коллекцию в качестве одного или нескольких своих членов, состоит в том, чтобы просто игнорировать их и вычислять GetHashCode исключительно на основе других скалярных членов. Это будет работать довольно хорошо, если только вы не поместите в хеш-таблицу огромное количество объектов, все их скалярные члены имеют одинаковые значения, что приведет к идентичным хэш-кодам.

Игнорирование членов коллекции при вычислении хэш-кода также может привести к повышению производительности, несмотря на уменьшение распределения значений хэш-кода. Помните, что использование хеш-кода должно улучшить производительность в хеш-таблице, поскольку не требует вызова Equals N раз, а вместо этого требует только один раз вызова GetHashCode и быстрого поиска в хеш-таблице. Если каждый объект имеет внутренний массив с 10 000 элементов, каждый из которых участвует в вычислении хеш-кода, все преимущества, полученные от хорошего распределения, вероятно, будут потеряны. Было бы лучше иметь немного менее распространенный хеш-код, если его создание обходится значительно дешевле.

public override int GetHashCode() {
   return Id.GetHashCode() ^ Values.GetHashCode();  
}

В комментариях и других ответах есть несколько хороших моментов. OP должен рассмотреть, будут ли значения использоваться как часть «ключа», если объект использовался в качестве ключа в словаре. Если да, то они должны быть частью хеш-кода, иначе нет.

С другой стороны, я не уверен, почему метод GetHashCode должен отражать SequenceEqual. Он предназначен для вычисления индекса в хеш-таблице, а не для полного определения равенства. Если при использовании описанного выше алгоритма возникает много коллизий хеш-таблиц, и если они различаются последовательностью значений, то следует выбрать алгоритм, учитывающий последовательность. Если последовательность не имеет большого значения, сэкономьте время и не принимайте ее во внимание.

Я бы сделал это так:

long result = Id.GetHashCode();
foreach(T val in Values)
    result ^= val.GetHashCode();
return result;

Я знаю, что этот поток довольно старый, но я написал этот метод, чтобы позволить мне вычислять хэш-коды нескольких объектов. Это было очень полезно для этого самого случая. Он не идеален, но он соответствует моим потребностям и, скорее всего, вашим.

Я не могу взять на себя ответственность за это. Я получил концепцию из некоторых реализаций .net gethashcode. Я использую 419 (в конце концов, это мое любимое большое простое число), но вы можете выбрать практически любое разумное простое число (не слишком маленькое... не слишком большое).

Итак, вот как я получаю свои хэш-коды:

using System.Collections.Generic;
using System.Linq;

public static class HashCodeCalculator
{
    public static int CalculateHashCode(params object[] args)
    {
        return args.CalculateHashCode();
    }

    public static int CalculateHashCode(this IEnumerable<object> args)
    {
        if (args == null)
            return new object().GetHashCode();

        unchecked
        {
            return args.Aggregate(0, (current, next) => (current*419) ^ (next ?? new object()).GetHashCode());
        }
    }
}

При условии, что Id и Values ​​никогда не изменятся, а Values ​​не равно null...

public override int GetHashCode()
{
  return Id ^ Values.GetHashCode();
}

Обратите внимание, что ваш класс не является неизменным, так как любой может изменить содержимое Values, потому что это массив. Учитывая это, я бы не стал генерировать хэш-код, используя его содержимое.