О реализации сравнения объектов по значению

Общеизвестно, что в объектной модели .NET, как и во многих других программных платформах, сравнивать объекты можно по ссылке и по значению.

По умолчанию два объекта считаются равными, если соответствующие переменные содержат одну и ту же ссылку.
В противном случае объекты считаются неравными.

Однако, может возникнуть ситуация, когда необходимо считать объекты некоторого класса равными, если они определенным образом совпадают по своему содержимому (тождественны).

Пусть есть класс Person, содержащий персональные данные — имя, фамилию, и дату рождения персоны.

На примере этого класса рассмотрим:

1. минимально необходимый набор доработок класса для того, чтобы объекты этого класса сравнивались по значению с помощью стандартной инфраструктуры .NET;
2. минимально необходимый и достаточный набор доработок, чтобы объекты этого класса всегда сравнивались по значению с помощью стандартной инфраструктуры .NET — если явно не указано, что сравнение должно производиться по ссылке.

Для каждого случая рассмотрим, каким именно образом лучше реализовать сравнение объектов по значению, чтобы получился согласованный и, насколько это возможно, компактный, copy-paste free, производительный код.

Задача является не настолько тривиальной, насколько это может показаться на первый взгляд.

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

Класс Person:

using System;

namespace HelloEquatable
{

    public class Person
    {
        private static string NormalizeName(string name) => name?.Trim() ?? string.Empty;

        private static DateTime? NormalizeDate(DateTime? date) => date?.Date;

        public string FirstName { get; }

        public string LastName { get; }

        public DateTime? BirthDate { get; }

        public Person(string firstName, string lastName, DateTime? birthDate)
        {
            this.FirstName = NormalizeName(firstName);
            this.LastName = NormalizeName(lastName);
            this.BirthDate = NormalizeDate(birthDate);
        }
    }

}

Если два объекта класса Person сравнивать любым способом:

• методом Object.ReferenceEquals(Object, Object) ^[1],
• методом Object.Equals(Object) ^[2],
• методом Object.Equals(Object, Object) ^[3],
• операторами == ^[4] или != ^[5],

то объекты будут считаться равными, только если соответствующие переменные содержат одну и ту же ссылку;
при помещении в хеш-наборы (хеш-карты) ^[6] и словари ^[7], объекты так же будут считаться равными только в случае совпадения ссылок.

В этом случае для сравнения объектов по значению в клиентском коде потребуется написать строки вида:

var p1 = new Person("John", "Smith", new DateTime(1990, 1, 1));
var p2 = new Person("John", "Smith", new DateTime(1990, 1, 1));

bool personEquals =
    p1.BirthDate == p2.BirthDate &&
    p1.FirstName == p2.FirstName &&
    p1.LastName == p2.LastName;

Примечания:

1. Класс Person реализован таким образом, что строковые свойства FirstName и LastName всегда не равны null ^[8].
   Если FirstName или LastName неизвестны (не заданы), то в качестве признака отсутствия значения подойдет пустая строка ^[9].
   Это позволит избежать исключения NullReferenceException ^[10] при обращении к свойствам и методам полей FirstName и LastName, а также коллизии при сравнении null ^[8] и пустой строки ^[9] (считать ли FirstName у двух объектов равными, если у одного объекта FirstName равен null ^[8], а у другого — пустой строке ^[9]?).
2. Свойство BirthDate, напротив, реализовано как Nullable(Of T) ^[11]-структура, т.к. в случае, если дата рождения неизвестна (не задана), то целесообразно сохранить в свойстве именно неопределенное значение, а не особое значение вида 01/01/1900, 01/01/1970, 01/01/0001 или MinValue ^[12], как это зачастую делается.
3. При сравнении объектов по значению первым реализовано сравнение дат, т.к. сравнение переменных типа дата-время в общем случае будет производиться быстрее, чем сравнение строк.
4. Сравнение дат и строк реализовано с помощью оператора равенства, т.к. оператор равенства сравнивает структуры по значению, а для строк оператор равенства перегружен и так же сравнивает строки по значению.

Для того, чтобы объекты класса Person можно было сравнивать по значению следующими способами:

• методом Object.Equals(Object) ^[2],
• методом Object.Equals(Object, Object) ^[3],
• при помещении в хеш-наборы (хеш-карты) ^[6] и словари ^[7],

у класса Person необходимо перекрыть методы Object.Equals(Object) ^[2] и Object.GetHashCode() ^[13], причем таким образом, чтобы:

• Метод Equals(Object) ^[2] сравнивал те поля класса, сочетание значений которых образует уникальное значение объекта.
• Для всяких двух объектов, для которых Equals(Object) ^[2] возвращает true ^[14], GetHashCode() ^[13] должен возвращать одинаковые значения (при этом два разных объекта могут иметь одинаковый хеш-код).
  Обычно используется результат операции «исключающее или» ^[15] значений GetHashCode() ^[13] полей, которые используются в Equals ^[2] для сравнения объектов по значению; в случае, если какое-либо поле является 32-битным целым, вместо хеш-кода этого поля может использоваться непосредственно значение поля.

Стоит обратить особое внимание, что в документации ^[2] к методу Equals(Object) ^[2] приведены специальные требования:

• x.Equals(y) returns the same value as y.Equals(x).
• If (x.Equals(y) && y.Equals(z)) returns true, then x.Equals(z) returns true.
• x.Equals(null) returns false.
• Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified.
• И ряд других, в частности, касающихся правил сравнения значений чисел с плавающей точкой.

Также стоит обратить внимание, что в документации ^[13] к методу GetHashCode() ^[13] приведено предупреждение, что значение, возвращаемое методом, не является постоянным значением, и поэтому его не следует сохранять на диск или в базу данных, использовать в качестве ключа, и т.д.

Класс Person с перекрытыми методами Equals(Object) ^[2] и GetHashCode() ^[13]:

using System;

namespace HelloEquatable
{

    public class Person
    {
        private static string NormalizeName(string name) => name?.Trim() ?? string.Empty;

        private static DateTime? NormalizeDate(DateTime? date) => date?.Date;

        public string FirstName { get; }

        public string LastName { get; }

        public DateTime? BirthDate { get; }

        public Person(string firstName, string lastName, DateTime? birthDate)
        {
            this.FirstName = NormalizeName(firstName);
            this.LastName = NormalizeName(lastName);
            this.BirthDate = NormalizeDate(birthDate);
        }

        public override int GetHashCode() =>
            this.FirstName.GetHashCode() ^
            this.LastName.GetHashCode() ^
            this.BirthDate.GetHashCode();

        public override bool Equals(object obj)
        {
            if ((object)this == obj)
                return true;

            var other = obj as Person;

            if ((object)other == null)
                return false;

            return
                this.BirthDate == other.BirthDate &&
                this.FirstName == other.FirstName &&
                this.LastName == other.LastName;
        }
    }

}

Примечания к методу GetHashCode() ^[13]:

• Если какое-либо из используемых полей содержит null ^[8], то для него вместо значения GetHashCode() ^[13] обычно используется ноль.
• Класс Person реализован таким образом, что ссылочные поля FirstName и LastName не могут содержать null ^[8], а поле BirthDate является Nullable(Of T) ^[11]-структурой, для которой в случае неопределенного значения GetHashCode() ^[13] возвращает ноль, и исключения NullReferenceException ^[10] при вызове GetHashCode() ^[13] не возникает.
• Если бы поля класса Person могли содержать null ^[8], то метод GetHashCode() ^[13] был бы реализован следующим образом:
  GetHashCode()

  public override int GetHashCode() =>
      this.FirstName?.GetHashCode() ?? 0 ^
      this.LastName?.GetHashCode() ?? 0 ^
      this.BirthDate?.GetHashCode() ?? 0;
  

Рассмотрим детально, как именно реализован метод Equals(Object) ^[2]:

1. Вначале ссылка на текущий объект (this ^[16]) сравнивается со ссылкой на входящий объектом, и если ссылки равны, возвращается true ^[14] (это один и тот же объект, и сравнение по значению не имеет смысла, в т.ч. из соображений производительности).
2. Затем выполняется приведение входящего объекта к типу Person с помощью оператора. Если результат приведения — null ^[8], то возвращается false ^[17] (либо входящая ссылка изначально была равна null ^[8], либо входящий объект имеет несовместимый с классом Person тип, и заведомо не равен текущему объекту).
3. Затем выполняется сравнение полей двух объектов класса Person по значению, и возвращается соответствующий результат.

Пока мы реализовали только минимально необходимую функциональность для сравнения объектов по значению, но уже появляются вопросы.

Первый вопрос больше теоретический.

Обратим внимание на требование к методу Equals(Object) ^[2]:

x.Equals(null) returns false.

Когда-то меня заинтересовало, почему некоторые экземплярные методы в стандартной библиотеке .NET проверяют this ^[16] на null ^[8] — например, так реализован метод String.Equals(Object) ^[18]:

public override bool Equals(Object obj) {
    //this is necessary to guard against reverse-pinvokes and
    //other callers who do not use the callvirt instruction
    if (this == null)
        throw new NullReferenceException();

    String str = obj as String;
    if (str == null)
        return false;

    if (Object.ReferenceEquals(this, obj))
        return true;

    if (this.Length != str.Length)
        return false;

     return EqualsHelper(this, str);
}

Первым делом в методе выполняется проверка this ^[16] на null ^[8] и, в случае положительного результата проверки, генерируется исключение NullReferenceException ^[10].
В комментарии указано, в каких случаях this ^[16] может принимать null ^[8]-значение.

(Кстати, сравнение this ^[16] на null ^[8] выполнено с помощью оператора == ^[4], который у класса String ^[19] перегружен ^[20], поэтому с точки зрения производительности проверку лучше сделать, явно приведя this ^[16] к object ^[21]: (object)this == null, или же воспользоваться методом Object.ReferenceEquals(Object, Object) ^[1], как это сделано во втором сравнении в этом же методе.)

А затем появилась статья, где об этом можно прочитать подробнее: Когда this == null: невыдуманная история из мира CLR ^[22].

Однако, в таком случае, если вызвать перегруженный метод Person.Equals(Object) без создания экземпляра, передав в качестве входного параметра null ^[8], то первая же строчка метода (if ((object)this == obj) return true;) возвратит true ^[14], что фактически будет правильно, но формально будет противоречить требованиям к реализации метода.

При этом в документации ^[2] к методу не указано, что первым делом нужно проверять this ^[16] на null ^[8] и генерировать исключение в случае успешной проверки.
Да и в таком случае следовало бы вообще во всех экземплярных методах всех классов первой строчкой проверять this ^[16] на null ^[8], что является абсурдом.

Поэтому представляется, что официальные требования к реализации метода Equals(Object) ^[2] должны быть уточнены следующим образом:

• (для классов, не структур) если ссылки на текущий и входящий объект равны, то возвращается true ^[14];
• и уже вторым требованием — если ссылка на входящий объекта равна null ^[8], то возвращается false ^[17].

А вот второй вопрос по реализации метода Equals(Object) ^[2] интереснее, и имеет прикладное значение.

Он касается того, как наиболее корректно реализовать требование:

x.Equals(y) returns the same value as y.Equals(x).

И того, полностью и непротиворечиво ли изложены в документации ^[2] требования и примеры к реализации метода в этой части, и есть ли альтернативные походы к реализации этого требования.

Об этом, так же как и о реализации полного набора доработок класса для сравнения его объектов по значению, поговорим в следующих публикациях.

Автор: sand14

Источник ^[23]