Лучшая практика выбора полей для реализации equals()

каковы наилучшие методы реализации equals, семантически, а не технически.

В Java метод equals действительно следует рассматривать как " identity equals" из-за того, как он интегрируется с реализациями Collection и Map. Рассмотрим следующее:

 public class Foo() {
    int id;
    String stuff;
 }

 Foo foo1 = new Foo(10, "stuff"); 
 fooSet.add(foo1);
 ...
 Foo foo2 = new Foo(10, "other stuff"); 
 fooSet.add(foo2);

Если Foo identity является полем id, то второе fooSet.add(...) не должно не добавлять еще один элемент в Set, но должно возвращать false, так как foo1 и foo2 имеют одинаковые id. Если вы определяете метод Foo.equals (и hashCode) для включения оба поля id и stuff, это может быть нарушено, поскольку Set может содержать 2 ссылки на объект с одним и тем же полем id.

Если вы не храните свои объекты в Collection (или Map), то вам не нужно определять метод equals таким образом, однако многие считают это дурным тоном. Если в будущем вы сделаете сохранение его в Collection, тогда все будет сломано.

Если мне нужно проверить равенство всех полей, я обычно пишу другой метод. Что-то вроде equalsAllFields(Object obj) или что-то в этом роде.

Тогда вы бы сделали что-то вроде:

assertTrue(obj1.equalsAllFields(obj2));

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

 Point p = new Point(1, 2);
 // ColoredPoint extends Point
 ColoredPoint c = new ColoredPoint(1, 2, Color.RED);
 // this is true because both points are at the location 1, 2
 assertTrue(p.equals(c));
 // however, this would return false because the Point p does not have a color
 assertFalse(c.equals(p));

Еще одно чтение, которое я настоятельно рекомендую, — это раздел «Подводный камень № 3: определение равенства с точки зрения изменяемых полей» на этой замечательной странице:

Как написать метод равенства на Java

Некоторые дополнительные ссылки:

• Реализация hashCode() и equals()
• Блог Graceful — значения, равенства и хэш-коды

Да, и просто для потомков, независимо от того, какие поля вы выбрали для сравнения для определения равенства, вам нужно использовать одни и те же поля в расчете hashCode. equals и hashCode должны быть симметричны. Если два объекта равны, они должны иметь одинаковый хэш-код. Обратное не обязательно верно.

Скопировано из Object.equals(Object obj) javadoc:

Указывает, является ли какой-либо другой объект «равным» этому.

Метод equals реализует отношение эквивалентности непустых ссылок на объекты:

• Это рефлексивно: для любого ненулевого ссылочного значения x функция x.equals(x) должна возвращать true.
• Он симметричен: для любых ненулевых ссылочных значений x и y функция x.equals(y) должна возвращать истину тогда и только тогда, когда y.equals(x) возвращает истину.
• Это транзитивно: для любых ненулевых ссылочных значений x, y и z, если x.equals(y) возвращает true, а y.equals(z) возвращает true, то x.equals(z) должен возвращать true.
• Он непротиворечив: для любых ненулевых ссылочных значений x и y множественные вызовы x.equals(y) последовательно возвращают true или последовательно возвращают false, при условии, что никакая информация, используемая в сравнениях на равенство для объектов, не изменяется.
• Для любого ненулевого ссылочного значения x функция x.equals(null) должна возвращать false.

Это довольно ясно для меня, так должны работать равные. Что касается выбора полей, вы выбираете ту комбинацию полей, которая требуется для определения является ли какой-либо другой объект «равным» этому объекту.

Что касается вашего конкретного случая, если вам в вашем тесте нужна более широкая область равенства, вы реализуете это в своем тесте. Вы не должны взламывать свой метод equals только для того, чтобы он подходил.

Вы должны использовать все значимые переменные, т.е. переменные, значение которых не является производным от других, в равных.

Это из эффективной Java:

Для каждого «значимого» поля в классе проверьте, соответствует ли это поле аргумента соответствующему полю этого объекта.

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

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

Я бы не стал думать о модульном тесте при написании equals(), они разные.

Вы определяете равенство каждого объекта с одним или группой свойств, реализуя equals() и hashcode().

В вашем тесте, если вы хотите сравнить все свойства объекта, то, очевидно, вам нужно вызвать каждый метод.

Я думаю, что лучше рассматривать их отдельно.

Я думаю, что единственной лучшей практикой при переопределении метода equals() является здравый смысл.

Правил нет, кроме определение эквивалентности API Java. После того, как вы выбрали это определение равенства, вы также должны применить его к своему методу hashCode().

Под этим я подразумеваю, что как разработчик вы, ваши коллеги и сопровождающие должны знать, когда ваш экземпляр, скажем, Watermelon равен другому экземпляру объекта.