Различия между IEquatable <T>, IEqualityComparer <T> и переопределением .Equals() при использовании LINQ в коллекции пользовательских объектов?

Ответ 1

Неважно, переопределяете ли вы object.Equals и object.GetHashCode, реализуете IEquatable или предоставляете IEqualityComparer. Все они могут работать несколько иначе.

1) Переопределение Equals и GetHashCode от object:

Это базовый случай, в некотором смысле. Как правило, это работает, предполагая, что вы в состоянии отредактировать тип, чтобы гарантировать, что реализация этих двух методов будет по желанию. Нет ничего плохого в том, чтобы делать это во многих случаях.

2) Реализация IEquatable

Ключевым моментом здесь является то, что вы можете (и должны) реализовать IEquatable<YourTypeHere>. Ключевое различие между этим и # 1 состоит в том, что у вас есть сильная типизация для метода Equals, а не просто использование object. Это лучше для удобства программиста (добавленный тип безопасности), а также означает, что любые типы значений не будут помещаться в бокс, поэтому это может повысить производительность для пользовательских структур. Если вы сделаете это, вы должны в значительной степени сделать это в дополнение к # 1, а не вместо. Наличие метода Equals здесь отличается функциональностью от object.Equals будет... плохой. Не делайте этого.

3) Реализация IEqualityComparer

Это полностью отличается от первых двух. Идея здесь в том, что объект не получает собственный хэш-код или видит, что он равен чему-то другому. Точка этого подхода состоит в том, что объект не знает, как правильно получить хэш или посмотреть, совпадает ли он с чем-то другим. Возможно, это потому, что вы не контролируете код типа (т.е. Стороннюю библиотеку), и они не удосужились переопределить поведение или, возможно, переопределили его, но вам просто нужно ваше собственное уникальное определение "равенства" в этот конкретный контекст.

В этом случае вы создаете полностью отдельный "сравнительный" объект, который принимает два разных объекта и информирует вас о том, являются они равными или нет или что представляет собой хэш-код одного объекта. При использовании этого решения не имеет значения, что делают методы Equals или GetHashCode в самом типе, вы не будете использовать его.

Обратите внимание, что все это полностью не связано с оператором ==, который является его собственным зверьем.

Ответ 2

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

class MyObject : IEquatable<MyObject> { 
  public bool Equals(MyObject other) { 
    if (Object.ReferenceEquals(other, null)) {
      return false;
    }

    // Actual equality logic here
  }

  public override int GetHashCode() { 
    // Actual Hashcode logic here
  }

  public override bool Equals(Object obj) {
    return Equals(obj as MyObject);
  }

  public static bool operator==(MyObject left, MyObject right) { 
    if (Object.ReferenceEquals(left, null)) {
      return Object.ReferenceEquals(right, null);
    }
    return left.Equals(right);
  }

  public static bool operator!=(MyObject left, MyObject right) {
    return !(left == right);
  }
}

Если вы следуете этому шаблону, нет необходимости предоставлять пользовательский IEqualityComparer<MyObject>. EqualityComparer<MyObject>.Default будет достаточно, поскольку он будет полагаться на IEquatable<MyObject> для выполнения проверок равенства

Ответ 3

Вы не можете "разрешить некоторый допуск на LastUpdate", а затем использовать реализацию GetHashCode(), которая использует строгое значение LastUpdate!

Предположим, что экземпляр this имеет LastUpdate в 23:13:13.933, а экземпляр obj имеет 23:13:13.932. Тогда эти два могут сравниться с вашей идеей толерантности. Но если это так, их хэш-коды должны быть одинаковыми. Но это не произойдет, если вам не очень повезло, поскольку DateTime.GetHashCode() не должен давать один и тот же хеш для этих двух раз.

Кроме того, ваш метод Equals может быть математически переходным. И "приблизительно равный" нельзя сделать переходным. Его транзитивное замыкание - это тривиальное отношение, которое идентифицирует все.