Я часто использую apache HashCodeBuilder и EqualsBuilder для равенства объектов, используя отражение, но недавно я, коллега, сказал мне, что использование отражения может привести к огромной производительности, если объект содержит множество свойств. Взволнованный, что я могу использовать неправильную реализацию, мой вопрос в том, какой из следующих способов вы предпочтете? И почему?
public class Admin {
private Long id;
private String userName;
public String getUserName() {
return userName;
}
@Override
public boolean equals(Object o) {
if (!(o instanceof Admin)) {
return false;
}
Admin otherAdmin = (Admin) o;
EqualsBuilder builder = new EqualsBuilder();
builder.append(getUserName(), otherAdmin.getUserName());
return builder.isEquals();
}
@Override
public int hashCode() {
HashCodeBuilder builder = new HashCodeBuilder();
builder.append(getUserName());
return builder.hashCode();
}
}
Vs.
public class Admin {
private Long id;
private String userName;
public String getUserName() {
return userName;
}
@Override
public boolean equals(Object o) {
return EqualsBuilder.reflectionEquals(this, o, Arrays.asList(id));
}
@Override
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this, Arrays.asList(id));
}
}
Конечно, второй вариант более изящный и простой. Но если вас беспокоит производительность, вы должны пойти на первый подход, второй метод также потерпит неудачу, если работает менеджер безопасности.
Я поеду на первый вариант, если бы был в вашей ситуации. Также есть ошибка в вашем первом подходе при генерации hashCode это должен быть return builder.toHashCode(); вместо return builder.hashCode(); (который возвращает hashcode объектов hashcode builder)
Я бы предпочел второй вариант по двум причинам:
Очевидно, что читать легче
Я бы не стал использовать аргументы производительности для первого параметра, если только они не включают соответствующую метрику. Например. сколько миллисекунд будет основано на отражениях "равно", добавить к типичной латентности конца в конец? В целом, какой процент будет увеличиваться? Не зная, что хорошие шансы на то, что оптимизация преждевременна
Несмотря на то, что второй вариант более привлекателен (потому что это всего лишь одна строка кода), я бы выбрал первый вариант.
Причина - просто производительность. После небольшого теста я нашел очень большую разницу во времени между ними.
Чтобы получить представление о времени, я создал два простых класса:
package equalsbuildertest;
import java.math.BigDecimal;
import java.util.Date;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
public class Class1 {
private int field1;
private boolean field2;
private BigDecimal field3;
private String field4;
private Date field5;
private long field6;
public Class1(int field1, boolean field2, BigDecimal field3, String field4,
Date field5, long field6) {
super();
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
this.field4 = field4;
this.field5 = field5;
this.field6 = field6;
}
public Class1() {
super();
}
public int getField1() {
return field1;
}
public void setField1(int field1) {
this.field1 = field1;
}
public boolean isField2() {
return field2;
}
public void setField2(boolean field2) {
this.field2 = field2;
}
public BigDecimal getField3() {
return field3;
}
public void setField3(BigDecimal field3) {
this.field3 = field3;
}
public String getField4() {
return field4;
}
public void setField4(String field4) {
this.field4 = field4;
}
public Date getField5() {
return field5;
}
public void setField5(Date field5) {
this.field5 = field5;
}
public long getField6() {
return field6;
}
public void setField6(long field6) {
this.field6 = field6;
}
@Override
public boolean equals(Object o) {
return EqualsBuilder.reflectionEquals(this, o);
}
@Override
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);
}
}
и
package equalsbuildertest;
import java.math.BigDecimal;
import java.util.Date;
import org.apache.commons.lang3.builder.EqualsBuilder;
import org.apache.commons.lang3.builder.HashCodeBuilder;
public class Class2 {
private int field1;
private boolean field2;
private BigDecimal field3;
private String field4;
private Date field5;
private long field6;
public Class2(int field1, boolean field2, BigDecimal field3, String field4,
Date field5, long field6) {
super();
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
this.field4 = field4;
this.field5 = field5;
this.field6 = field6;
}
public Class2() {
super();
}
public int getField1() {
return field1;
}
public void setField1(int field1) {
this.field1 = field1;
}
public boolean isField2() {
return field2;
}
public void setField2(boolean field2) {
this.field2 = field2;
}
public BigDecimal getField3() {
return field3;
}
public void setField3(BigDecimal field3) {
this.field3 = field3;
}
public String getField4() {
return field4;
}
public void setField4(String field4) {
this.field4 = field4;
}
public Date getField5() {
return field5;
}
public void setField5(Date field5) {
this.field5 = field5;
}
public long getField6() {
return field6;
}
public void setField6(long field6) {
this.field6 = field6;
}
@Override
public boolean equals(Object obj) {
if (!(obj instanceof Class2)) {
return false;
}
Class2 other = (Class2) obj;
EqualsBuilder builder = new EqualsBuilder();
builder.append(field1, other.field1);
builder.append(field2, other.field2);
builder.append(field3, other.field3);
builder.append(field4, other.field4);
builder.append(field5, other.field5);
builder.append(field6, other.field6);
return builder.isEquals();
}
@Override
public int hashCode() {
HashCodeBuilder builder = new HashCodeBuilder();
builder.append(getField1());
builder.append(isField2());
builder.append(getField3());
builder.append(getField4());
builder.append(getField5());
builder.append(getField6());
return builder.hashCode();
};
}
Этот второй класс почти такой же, как первый, но с разными equals и hashCode.
После этого я создал следующие тесты:
package equalsbuildertest;
import static org.junit.Assert.*;
import java.math.BigDecimal;
import java.util.Date;
import org.junit.Test;
public class EqualsBuilderTest {
@Test
public void test1() {
Class1 class1a = new Class1(1, true, new BigDecimal(0), "String", new Date(), 1L);
Class1 class1b = new Class1(1, true, new BigDecimal(0), "String", new Date(), 1L);
for (int i = 0; i < 1000000; i++) {
assertEquals(class1a, class1b);
}
}
@Test
public void test2() {
Class2 class2a = new Class2(1, true, new BigDecimal(0), "String", new Date(), 1L);
Class2 class2b = new Class2(1, true, new BigDecimal(0), "String", new Date(), 1L);
for (int i = 0; i < 1000000; i++) {
assertEquals(class2a, class2b);
}
}
}
Тест довольно прост и служит только для измерения времени.
Результаты были следующими:
Я выбрал их полностью равными, чтобы иметь наибольшее время. Если вы решите выполнить тест с условиями NotEquals, у вас будет меньше времени, но также будет очень большой разницы во времени.
Я запускаю эти тесты на 64-битном процессоре Intel Core i5-3317U с частотой 1,70 ГГц x4 с Fedora 21 и Eclipse Luna.
В заключение я бы не стал рисковать такой большой разницей в производительности, чтобы сохранить пару строк кода, которые вы, возможно, не можете вводить в любом случае с помощью шаблона (в Eclipse под Windows → Настройки находятся в Java → Редактор → Шаблоны), например:
${:import(org.apache.commons.lang3.builder.HashCodeBuilder, org.apache.commons.lang3.builder.EqualsBuilder)}
@Override
public int hashCode() {
HashCodeBuilder hashCodeBuilder = new HashCodeBuilder();
hashCodeBuilder.append(${field1:field});
hashCodeBuilder.append(${field2:field});
hashCodeBuilder.append(${field3:field});
hashCodeBuilder.append(${field4:field});
hashCodeBuilder.append(${field5:field});
return hashCodeBuilder.toHashCode();
}
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
${enclosing_type} rhs = (${enclosing_type}) obj;
EqualsBuilder equalsBuilder = new EqualsBuilder();
equalsBuilder.append(${field1}, rhs.${field1});
equalsBuilder.append(${field2}, rhs.${field2});
equalsBuilder.append(${field3}, rhs.${field3});
equalsBuilder.append(${field4}, rhs.${field4});
equalsBuilder.append(${field5}, rhs.${field5});${cursor}
return equalsBuilder.isEquals();
}
Ваш написанный вами вопрос ясно иллюстрирует одно из преимуществ второго подхода:
В первом случае очень легко сделать ошибку return builder.hashCode() вместо правильного return builder.toHashCode(), что приведет к тонким ошибкам, которые могут быть очень трудными для отслеживания.
Второй случай исключает возможность этой опечатки, в результате чего вы ударяете головой в клавиатуру, пытаясь найти ошибку.
Я бы сказал, что ни одна из них не является хорошей реализацией. Я бы сказал, что EqualsBuilder не является хорошей основой для использования по следующим причинам:
Я скажу, что должна быть лучшая структура, чем Apache.
Согласитесь с @Churk, Apache HashCodeBuilder и EqualsBuilder не реализованы хорошо. HashCodeBuilder все еще играет с простыми номерами! Кроме того, он делает очень много ненужной работы. Вы читали источник?
Так как Java 5 (если не раньше), AbstractHashMap < > не использовал по модулю простого числа, чтобы найти хэш-ведро. Вместо этого количество ведер - это мощность двух, а младшие бит N-х хэш-кода используются для определения местоположения ведра.
Кроме того, он будет "смешивать" хэш-код, предоставляемый приложением, чтобы биты распределялись равномерно, и, таким образом, ведра заполнялись равномерно.
Таким образом, правильный способ переопределения int Object.hashCode() заключается в возврате простейшего, постоянного значения с наивысшей arity в совокупности объектов, которые будут сожительствовать в любой коллекции с использованием класса.
Как правило, значение немодифицированного идентификатора - ваш лучший выбор. Если ваше поле идентификатора является целостным, просто отбросьте его (int) и верните. Если это String или другой объект, просто верните его хэш-код. Вы поняли эту идею. Для составного идентификатора возвращайте поле (или его hashCode) с самыми разными значениями. Меньше - больше.
Конечно, контракт между hashCode() и equals() должен быть выполнен. Таким образом, equals() должно быть реализовано соответствующим образом. hashCode() не обязательно использовать полные квалификаторы, необходимые для равенства, но любые поля, используемые в hashCode(), должны использоваться в equals(). Здесь методы, подобные StringUtils.equals(s1, s2), полезны для непрерывного и безопасного обращения с нулевыми значениями.