Нужно ли переопределять операции == и!= При переопределении метода Equals? (.СЕТЬ)

Ответ 1

См. рекомендации для переопределения Equals() и оператора ==.

Цитата:

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

В принципе:

Если вы хотите, чтобы == и!= вел себя как Equals(..) и !Equals(..), вам нужно реализовать операторы. Обычно вы делаете это только с неизменяемыми типами.

Ответ 2

См. Рекомендации по внедрению равных и оператор равенства (==)

Для типов значений (structs) "Реализовать == в любое время, когда вы переопределите метод Equals"

Для ссылочных типов (классов): "Большинство ссылочных типов, даже те, которые реализуют метод Equals, не должны переопределять ==." Исключение составляет для неизменяемых классов и те, у которых есть ценностная семантика.

Ответ 3

В дополнение ко всем ответам уже здесь, не забудьте гарантировать, что GetHashCode() также согласован.

Ответ 4

Если вы переопределяете метод equals и все еще хотите иметь возможность проверить равенство (или неравенство), вы должны, вероятно, переопределить методы == и! =.

Ответ 5

Это не обязательно, но умная вещь.

Если вы создаете фреймворк и другой разработчик, кроме того, что собираетесь использовать объект, вы должны переопределить == и! =. Таким образом, когда разработчик может использовать его, у них, по крайней мере, есть правильная логика для сравнения двух объектов, а не просто одинаковых в памяти.

Я бы удостоверился, что ваши == и!= вызывают метод equals.

Ответ 6

Было бы желательно, так как было бы неожиданно, если:

if (foo == bar)

... вел себя по-другому:

if (foo.Equals(bar))

Ответ 7

Нет необходимости, никто не убьет вас, если вы этого не сделаете.

Однако обратите внимание, что часто более естественно писать (A == B), чем A.Equals(B). Если вы предоставите оба метода, пользователям будет проще использовать ваш код.

Ответ 8

в A.Equals(B) A не может быть нулевым в A == B либо может быть null

Ответ 9

Переопределение ==, чтобы вызвать его, Equals поражает меня как вообще плохую идею для ссылочных типов. Если вы переопределяете ==, чтобы заставить его вызывать Equals, то я не думаю, что есть способ для пользователя вашего кода проверить, ссылаются ли ссылки на два объекта на один и тот же объект (по сравнению с объектом с равными свойствами).

Если люди хотят тестировать экземпляры ваших классов для равенства по значению, то, безусловно, они должны просто вызвать Equals, сохраняя == для проверки ссылочного равенства.