Apache Commons equals/hashCode builder

Ответ 1

Создатели commons/lang великолепны, и я использую их в течение многих лет без заметных издержек производительности (с и без спящего режима). Но, как пишет Ален, путь Гува еще приятнее:

Здесь пример Bean:

public class Bean{

    private String name;
    private int length;
    private List<Bean> children;

}

Здесь equals() и hashCode() реализованы с помощью Commons/Lang:

@Override
public int hashCode(){
    return new HashCodeBuilder()
        .append(name)
        .append(length)
        .append(children)
        .toHashCode();
}

@Override
public boolean equals(final Object obj){
    if(obj instanceof Bean){
        final Bean other = (Bean) obj;
        return new EqualsBuilder()
            .append(name, other.name)
            .append(length, other.length)
            .append(children, other.children)
            .isEquals();
    } else{
        return false;
    }
}

и здесь с Guava:

@Override
public int hashCode(){
    return Objects.hashCode(name, length, children);
}

@Override
public boolean equals(final Object obj){
    if(obj instanceof Bean){
        final Bean other = (Bean) obj;
        return Objects.equal(name, other.name)
            && length == other.length // special handling for primitives
            && Objects.equal(children, other.children);
    } else{
        return false;
    }
}

Как вы видите, версия Guava короче и позволяет избежать лишних вспомогательных объектов. В случае равных, это даже допускает короткое замыкание оценки, если предыдущий вызов Object.equal() возвращает false (справедливо: commons/lang имеет метод ObjectUtils.equals(obj1, obj2) с идентичной семантикой, который можно использовать вместо EqualsBuilder для позвольте короткому замыканию, как указано выше).

Итак: да, разработчики commons lang очень предпочтительнее созданных вручную методов equals() и hashCode() (или тех ужасных монстров, которые Eclipse будет генерировать для вас), но версии Guava еще лучше.

И записка о Hibernate:

будьте осторожны с использованием ленивых коллекций в реализациях equals(), hashCode() и toString(). Это будет неудачно, если у вас нет открытого сеанса.

Примечание (около equals()):

a) в обеих версиях equals() выше, вы можете также использовать один или оба этих ярлыка:

@Override
public boolean equals(final Object obj){
    if(obj == this) return true;  // test for reference equality
    if(obj == null) return false; // test for null
    // continue as above

b) в зависимости от вашей интерпретации договора equals(), вы также можете изменить строку (и)

    if(obj instanceof Bean){

к

    // make sure you run a null check before this
    if(obj.getClass() == getClass()){ 

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

правильный способ включения суперкласса в реализацию объекта Guava Objects.hashcode()

(хотя это примерно hashCode(), то же самое относится к equals())

Примечание (вдохновлено комментарием kayahr)

Objects.hashCode(..) (так же, как базовый Arrays.hashCode(...)) может работать плохо, если у вас много примитивных полей. В таких случаях EqualsBuilder может быть лучшим решением.

Ответ 2

Люди, проснись! Так как Java 7 существуют вспомогательные методы для equals и hashCode в стандартная библиотека. Их использование полностью эквивалентно использованию методов Guava.

Ответ 3

Если вы не хотите зависеть от сторонней библиотеки (возможно, у вас запущено устройство с ограниченными ресурсами), и даже вы не хотите вводить свои собственные методы, вы также можете позволить IDE выполнять задание, например. в использовании eclipse

Source -> Generate hashCode() and equals()...

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

Пример (затмение Juno):

import java.util.Arrays;
import java.util.List;

public class FooBar {

    public String string;
    public List<String> stringList;
    public String[] stringArray;

    /* (non-Javadoc)
     * @see java.lang.Object#hashCode()
     */
    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((string == null) ? 0 : string.hashCode());
        result = prime * result + Arrays.hashCode(stringArray);
        result = prime * result
                + ((stringList == null) ? 0 : stringList.hashCode());
        return result;
    }
    /* (non-Javadoc)
     * @see java.lang.Object#equals(java.lang.Object)
     */
    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        FooBar other = (FooBar) obj;
        if (string == null) {
            if (other.string != null)
                return false;
        } else if (!string.equals(other.string))
            return false;
        if (!Arrays.equals(stringArray, other.stringArray))
            return false;
        if (stringList == null) {
            if (other.stringList != null)
                return false;
        } else if (!stringList.equals(other.stringList))
            return false;
        return true;
    }

}

Ответ 4

У EqualsBuilder и HashCodeBuilder есть два основных аспекта, которые отличаются от написанного вручную кода:

• null обработка
• создание экземпляра

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

EqualsBuilder, с другой стороны, создаст вызов экземпляра за один равный метод. Если ваши методы equals вызываются часто, это создаст много экземпляров.

Для Hibernate реализация equals и hashCode не имеет значения. Это всего лишь деталь реализации. Для почти всех объектов домена, загруженных спящим режимом, служебные данные времени выполнения (даже без анализа escape) Builder можно игнорировать. База данных и коммуникационные издержки будут значительными.

Как сказал скаффман, версия отражения не может использоваться в производственном коде. Отражение будет замедляться, и "реализация" будет неправильной для всех, кроме простейших классов. Учет всех членов также опасен, поскольку вновь введенные члены меняют поведение метода равных. Версия отражения может быть полезна в тестовом коде.

Ответ 5

Если вы не хотите писать свои собственные, есть возможность использовать google guava (ранее коллекции google)

Ответ 6

Если вы просто имеете дело с сущностью bean, где id является первичным ключом, вы можете упростить.

   @Override
   public boolean equals(Object other)
   {
      if (this == other) { return true; }
      if ((other == null) || (other.getClass() != this.getClass())) { return false; }

      EntityBean castOther = (EntityBean) other;
      return new EqualsBuilder().append(this.getId(), castOther.getId()).isEquals();
   }

Ответ 7

По-моему, это не очень хорошо сочетается с Hibernate, особенно примеры из ответа, сравнивающего длину, имя и дочерние элементы для некоторого объекта. Hibernate советует использовать бизнес-ключ для использования в equals() и hashCode(), и у них есть свои причины. Если вы используете генераторы auto equals() и hashCode() на своем бизнес-ключе, это нормально, только проблемы с производительностью необходимо учитывать, как упоминалось ранее. Но люди обычно используют все свойства, что ИМО ошибочно. Например, я в настоящее время работает над проектом, где объекты написаны с использованием Pojomatic с @AutoProperty, что я считаю очень неудачным.

Их два основных сценария использования hashCode() и equals():

• когда вы помещаете экземпляры постоянных классов в Set ( рекомендуемый способ представления многозначных ассоциаций) и
• при повторном подключении отдельных экземпляров

Итак, предположим, что наш объект выглядит следующим образом:

class Entity {
  protected Long id;
  protected String someProp;
  public Entity(Long id, String someProp);
}

Entity entity1 = new Entity(1, "a");
Entity entity2 = new Entity(1, "b");

Оба являются одним и тем же объектом для Hibernate, которые были извлечены из некоторого сеанса в какой-то момент (их id и class/table равны). Но когда мы реализуем auto equals() hashCode() на всех реквизитах, что у нас есть?

• Когда вы помещаете сущность2 в постоянный набор, где сущность1 уже существует, это будет помещено дважды и приведет к исключению во время фиксации.
• Если вы хотите присоединить выделенный элемент2 к сеансу, где сущность1 уже существует, они (вероятно, я не тестировал это особенно) не будут правильно объединены.

Итак, для 99% проекта, который я делаю, мы используем следующую реализацию equals() и hashCode(), написанную один раз в классе базовой сущности, которая согласуется с концепциями Hibernate:

@Override
public boolean equals(Object obj) {
    if (StringUtils.isEmpty(id))
        return super.equals(obj);

    return getClass().isInstance(obj) && id.equals(((IDomain) obj).getId());
}

@Override
public int hashCode() {
    return StringUtils.isEmpty(id)
        ? super.hashCode()
        : String.format("%s/%s", getClass().getSimpleName(), getId()).hashCode();
}

Для переходного объекта я делаю то же самое, что Hibernate будет делать на шаге упорства, т.е. Я использую совпадение экземпляра. Для постоянных объектов я сравниваю уникальный ключ, который является таблицей /id (я никогда не использую составные клавиши).

Ответ 8

На всякий случай, другие найдут это полезным, я придумал этот класс Helper для вычисления хеш-кода, который позволяет избежать дополнительных накладных расходов на создание объектов, упомянутых выше (на самом деле, накладные расходы метода Objects.hash() еще больше когда у вас есть наследование, поскольку оно создаст новый массив на каждом уровне!).

Пример использования:

public int hashCode() {
    return HashCode.hash(HashCode.hash(timestampMillis), name, dateOfBirth); // timestampMillis is long
}

public int hashCode() {
    return HashCode.hash(super.hashCode(), occupation, children);
}

Помощник HashCode:

public class HashCode {

    public static int hash(Object o1, Object o2) {
        return add(Objects.hashCode(o1), o2);
    }

    public static int hash(Object o1, Object o2, Object o3) {
        return hash(Objects.hashCode(o1), o2, o3);
    }

    ...

    public static int hash(Object o1, Object o2, ..., Object o10) {
        return hash(Objects.hashCode(o1), o2, o3, ..., o10);
    }

    public static int hash(int initial, Object o1, Object o2) {
        return add(add(initial, o1), o2);
    }

    ...

    public static int hash(int initial, Object o1, Object o2, ... Object o10) {
        return add(... add(add(add(initial, o1), o2), o3) ..., o10);
    }

    public static int hash(long value) {
        return (int) (value ^ (value >>> 32));
    }

    public static int hash(int initial, long value) {
        return add(initial, hash(value));
    }

    private static int add(int accumulator, Object o) {
        return 31 * accumulator + Objects.hashCode(o);
    }
}

Я понял, что 10 - это максимально допустимое количество свойств в модели домена, если у вас есть больше, вы должны думать о рефакторинге и вводить больше классов вместо сохранения кучи строк и примитивов.

Недостатки: это не полезно, если у вас есть в основном примитивы и/или массивы, которые вам нужно глубоко использовать. (Обычно это так, когда вам приходится иметь дело с плоскими (переносными) объектами, которые находятся вне вашего контроля).