Нужно ли переопределять операторы == и! = При переопределении метода Equals? (.СЕТЬ) - PullRequest
10 голосов
/ 03 августа 2009

Или это целесообразно сделать? Почему?

Ответы [ 9 ]

26 голосов
/ 03 августа 2009

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

Цитата:

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

В основном:

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

5 голосов
/ 03 августа 2009

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

Для типов значений (структур) "Реализация == каждый раз, когда вы переопределяете метод Equals"

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

2 голосов
/ 03 августа 2009

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

1 голос
/ 11 августа 2010

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

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

1 голос
/ 15 октября 2009

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

1 голос
/ 03 августа 2009

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

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

1 голос
/ 03 августа 2009

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

if (foo == bar)

... вел себя иначе, чем:

if (foo.Equals(bar))
1 голос
/ 03 августа 2009

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

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

Я бы гарантировал, что ваш == &! = Do вызовет ваш метод equals.

1 голос
/ 03 августа 2009

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

...