Правильный способ реализовать равняется контракту [дубликат]
4 ответа
Это (почти) верно для «технического равенства», но не для «естественного равенства». Чтобы достичь максимального технического равенства, вы также должны протестировать рефлексивное o == this . Может случиться так, что объект еще не сохранен в БД и, следовательно, еще не имеет технического идентификатора. Например.
public class User {
private Long id;
@Override
public boolean equals(Object object) {
return (object instanceof User) && (id != null)
? id.equals(((User) object).id)
: (object == this);
}
@Override
public int hashCode() {
return (id != null)
? (User.class.hashCode() + id.hashCode())
: super.hashCode();
}
}
Для «естественного равенства» лучше сравнивать все нетехнические свойства. Для «сущностей реального мира» это, в конце концов, надежнее (но и дороже), чем техническое равенство.
public class User {
private String name;
private Date birth;
private int housenumber;
private long phonenumber;
@Override
public boolean equals(Object object) {
// Basic checks.
if (object == this) return true;
if (!(object instanceof User)) return false;
// Property checks.
User other = (User) object;
return Objects.equals(name, other.name)
&& Objects.equals(birth, other.birth)
&& (housenumber == other.housenumber)
&& (phonenumber == other.phonenumber);
}
@Override
public int hashCode() {
return Objects.hash(name, birth, housenumber, phonenumber);
}
}
Да, это много кода, когда много свойств. Немного приличная IDE (Eclipse, Netbeans и т. Д.) Может просто автоматически сгенерировать equals () , hashCode () (а также toString () , геттеры и сеттеры) для тебя. Воспользуйтесь этим. В Eclipse щелкните код правой кнопкой мыши и выберите пункт меню Источник (Alt + Shift + S).
См. Также:
То, что вы делаете, кажется нормальным, и вы не нарушаете ни одно из правил , которым должно следовать равно .
Вы все равно можете проверить другие поля, но не для изменения семантики , равной , а для обнаружения несоответствия в вашей бизнес-логике и, возможно, для запуска утверждения / исключения.
Если в вашей модели ssoid должен быть уникальным, это означает, что значения других полей не должны отличаться для двух экземпляров User. Если вы хотите проверить это предположение, вы можете сделать это с помощью утверждений в методе equals, если накладные расходы не являются проблемой.
Это непростое решение.
Это проблема, в которую я попал, рассматривая возможность хеширования несколько месяцев назад. Я предлагаю вам прочитать, что такое хеш, потому что он очень важен для вашего ответа ... Я предлагаю вам реализовать какой-то хеш и проверить его равенство.
Существуют разные виды равенства ... есть равенство идентичности объекта, равенство данных объекта, равенство всего объекта ... вы также можете включить сюда аудиторскую информацию .
Дело в том, что «равно» имеет много возможных значений.
Я решил эту проблему, реализовав равенство как строгое равенство во всех областях просто потому, что после расспросов мне кажется, что это интуитивное значение равенства. Затем я построил методы для других видов равенства, которые мне требовались, и определил интерфейс для их обертывания.
Я бы не стал проверять равенство на object == this, потому что часто вы тестируете два разных объекта с одинаковыми данными, которые в моей книге равны, несмотря на то, что они ссылаются на разные адреса памяти.