Чи є утиліта відображення Java для глибокого порівняння двох об'єктів?

Я намагаюся писати одиничні тести для різних clone()операцій у великому проекті, і мені цікаво, чи існує десь клас, який здатний приймати два об'єкти одного типу, робити глибоке порівняння і говорити, чи вони ти однаковий чи ні?

Unitils має цю функціональність:

Затвердження рівності за допомогою рефлексії, з різними варіантами, такими як ігнорування значень за замовчуванням / нуль Java та ігнорування порядку колекцій

Я люблю це питання! Головним чином, тому, що на нього навряд чи можна відповісти погано. Наче ніхто ще не зрозумів цього. Діва територія :)

По-перше, навіть не думайте про використання equals. Договір equals, як визначено в javadoc, - це відношення еквівалентності (рефлексивне, симетричне та перехідне), а не відношення рівності. Для цього це також мало би бути антисиметричним. Єдине втілення equalsцього - це (або коли-небудь могло б бути) справжнього відношення рівності - це те, що в java.lang.Object. Навіть якщо ви equalsпорівнювали все на графіку, ризик розірвати контракт досить високий. Як вказував Джош Блох в « Ефективній Java» , контракт рівних дуже просто розірвати:

"Просто немає способу розширити клас миттєвих даних і додати аспект при збереженні контракту на рівні"

Окрім того, чим корисним є булевий метод насправді? Було б непогано насправді інкапсулювати всі відмінності між оригіналом та клоном, ви не думаєте? Крім того, тут я припускаю, що вам не хочеться заважати писати / підтримувати код порівняння для кожного об'єкта в графіку, а швидше ви шукаєте те, що буде змінюватися з джерелом, оскільки воно змінюється з часом.

Soooo, те, що ви дійсно хочете, це якийсь інструмент порівняння стану. Те, як цей інструмент реалізований, дійсно залежить від характеру вашої доменної моделі та ваших обмежень на продуктивність. На мій досвід, немає жодної родової магічної кулі. І це буде повільно через велику кількість ітерацій. Але для перевірки повноти операції з клонуванням це зробить роботу досить добре. Ваші два найкращі варіанти - серіалізація та рефлексія.

Деякі проблеми, з якими ви зіткнетесь:

• Порядок колекції: чи слід вважати дві колекції схожими, якщо вони містять однакові предмети, але в іншому порядку?
• Які поля ігнорувати: Тимчасові? Статичний?
• Еквівалентність типу: чи мають значення поля точно такого ж типу? Або нормально, щоб один продовжував інший?
• Є більше, але я забуваю ...

XStream досить швидкий і в поєднанні з XMLUnit зробить роботу лише за кілька рядків коду. XMLUnit приємний тим, що він може повідомити про всі відмінності або просто зупинитися на першому, який знайде. І його вихід включає xpath до різних вузлів, що добре. За замовчуванням він не дозволяє невпорядковані колекції, але це можна налаштувати для цього. Введення спеціального обробника різниці (Called a DifferenceListener) дозволяє вказати спосіб вирішення розбіжностей, включаючи ігнорування порядку. Однак, як тільки ви хочете зробити що-небудь за межі найпростішого налаштування, писати стає важко, і деталі, як правило, прив'язуються до конкретного об’єкта домену.

Мої особисті переваги - використовувати рефлексію, щоб переглядати всі задекларовані поля та переглядати кожне з них, відстежуючи відмінності, як я йду. Слово попередження: Не використовуйте рекурсії, якщо вам не подобаються винятки переповнення стека. Зберігайте речі в обсязі стеком (використовуйте aLinkedListабо щось). Зазвичай я ігнорую перехідні та статичні поля, і пропускаю об'єктні пари, які я вже порівняв, тому я не опиняюся у нескінченних петлях, якщо хтось вирішив написати самореференційний код (Однак я завжди порівнюю примітивні обгортки незалежно від того, що , оскільки одні і ті ж реф. об'єкти часто повторно використовуються). Ви можете налаштувати речі наперед, щоб ігнорувати впорядкування колекції та ігнорувати спеціальні типи чи поля, але мені подобається визначати мою політику порівняння стану на самих полях через анотації. Саме для цього, IMHO - саме те, що було призначено для анотацій, щоб зробити метадані про клас доступними під час виконання. Щось на зразок:

@StatePolicy(unordered=true, ignore=false, exactTypesOnly=true)
private List<StringyThing> _mylist;

Я думаю, що це насправді дуже важка проблема, але повністю вирішена! І як тільки у вас є щось, що працює для вас, це дійсно, справді, зручно :)

Отже, удачі. І якщо ви придумали щось просто геніальне, не забудьте поділитися!

Дивіться DeepEquals та DeepHashCode () в межах java-util: https://github.com/jdereg/java-util

Цей клас робить саме те, що вимагає оригінальний автор.

Перевизначення Метод рівних ()

Ви можете просто змінити метод equals () класу, використовуючи EqualsBuilder.reflectionEquals (), як пояснено тут :

 public boolean equals(Object obj) {
   return EqualsBuilder.reflectionEquals(this, obj);
 }

Просто довелося здійснити порівняння двох екземплярів сутності, переглянутого Hibernate Envers. Я почав писати свою різницю, але потім знайшов наступну основу.

https://github.com/SQiShER/java-object-diff

Ви можете порівняти два об'єкти одного типу, і вони покажуть зміни, доповнення та видалення. Якщо змін немає, то об'єкти рівні (теоретично). Анотації надаються особам, які слід ігнорувати під час перевірки. Робота з кадрами має набагато ширші програми, ніж перевірка рівності, тобто я використовую для створення журналу змін.

Його продуктивність гаразд, порівнюючи об'єкти JPA, спочатку не забудьте від'єднати їх від менеджера об'єктів.

Я використовую XStream:

/**
 * @see java.lang.Object#equals(java.lang.Object)
 */
@Override
public boolean equals(Object o) {
    XStream xstream = new XStream();
    String oxml = xstream.toXML(o);
    String myxml = xstream.toXML(this);

    return myxml.equals(oxml);
}

/**
 * @see java.lang.Object#hashCode()
 */
@Override
public int hashCode() {
    XStream xstream = new XStream();
    String myxml = xstream.toXML(this);
    return myxml.hashCode();
}

У AssertJ ви можете:

Assertions.assertThat(expectedObject).isEqualToComparingFieldByFieldRecursively(actualObject);

Напевно, це не спрацює у всіх випадках, однак воно буде працювати у більшості випадків, про які ви думаєте.

Ось що говорить документація:

Стверджують, що досліджуваний об'єкт (фактичний) дорівнює даному об'єкту на основі рекурсивної властивості / поля за порівнянням властивостей / полів (включаючи спадкові). Це може бути корисно, якщо реальна реалізація не відповідає вам. Рекурсивне порівняння властивостей / полів не застосовується для полів, що мають власну реалізацію рівних, тобто метод замінення рівних буде використаний замість порівняння поля за полем.

Рекурсивне порівняння обробляє цикли. За замовчуванням поплавці порівнюються з точністю до 1,0Е-6 і подвоюються з 1,0Е-15.

Ви можете вказати спеціальний компаратор для (вкладених) полів або типу, використовуючи відповідноComparatorForFields (Comparator, String ...) та використовуючиComparatorForType (Comparator, Class).

Об'єкти для порівняння можуть бути різних типів, але повинні мати однакові властивості / поля. Наприклад, якщо фактичний об'єкт має ім'я String, очікується, що інший об'єкт також має його. Якщо об’єкт має поле та властивість з тим самим іменем, значення властивості буде використано над полем.

http://www.unitils.org/tutorial-reflectionassert.html

public class User {

    private long id;
    private String first;
    private String last;

    public User(long id, String first, String last) {
        this.id = id;
        this.first = first;
        this.last = last;
    }
}

User user1 = new User(1, "John", "Doe");
User user2 = new User(1, "John", "Doe");
assertReflectionEquals(user1, user2);

У Hamcrest є Matcher той же самийPropertyValuesAs . Але він покладається на Конвенцію JavaBeans (використовує геттери та сетери). Якщо об'єкти, які слід порівнювати, не мають гетерів та сеттерів для своїх атрибутів, це не спрацює.

import static org.hamcrest.beans.SamePropertyValuesAs.samePropertyValuesAs;
import static org.junit.Assert.assertThat;

import org.junit.Test;

public class UserTest {

    @Test
    public void asfd() {
        User user1 = new User(1, "John", "Doe");
        User user2 = new User(1, "John", "Doe");
        assertThat(user1, samePropertyValuesAs(user2)); // all good

        user2 = new User(1, "John", "Do");
        assertThat(user1, samePropertyValuesAs(user2)); // will fail
    }
}

Користувач - з геттерами та сетерами

public class User {

    private long id;
    private String first;
    private String last;

    public User(long id, String first, String last) {
        this.id = id;
        this.first = first;
        this.last = last;
    }

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getFirst() {
        return first;
    }

    public void setFirst(String first) {
        this.first = first;
    }

    public String getLast() {
        return last;
    }

    public void setLast(String last) {
        this.last = last;
    }

}

Якщо ваші об'єкти реалізують Serializable, ви можете використовувати це:

public static boolean deepCompare(Object o1, Object o2) {
    try {
        ByteArrayOutputStream baos1 = new ByteArrayOutputStream();
        ObjectOutputStream oos1 = new ObjectOutputStream(baos1);
        oos1.writeObject(o1);
        oos1.close();

        ByteArrayOutputStream baos2 = new ByteArrayOutputStream();
        ObjectOutputStream oos2 = new ObjectOutputStream(baos2);
        oos2.writeObject(o2);
        oos2.close();

        return Arrays.equals(baos1.toByteArray(), baos2.toByteArray());
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

Ваш приклад пов'язаного списку не так вже й важко обробляти. Коли код обходить два графіки об'єкта, він розміщує відвідані об'єкти у наборі чи карті. Перед тим, як перейти до іншої посилання на об'єкт, цей набір перевіряється, щоб перевірити, чи об'єкт вже пройшов. Якщо так, не потрібно йти далі.

Я погоджуюся з людиною, яка сказала, що використовує LinkedList (як Stack, але без синхронізованих методів на ньому, так це швидше). Переміщення графіку об'єкта за допомогою стека, використовуючи відображення для отримання кожного поля, є ідеальним рішенням. Написаний один раз, цей "зовнішній" дорівнює () і "зовнішній" hashCode () - це те, що всі методи рівняння () та hashCode () повинні викликати. Ніколи більше не потрібен метод клієнта рівний ().

Я написав трохи коду, який проходить повний графік об'єкта, перелічений у Google Code. Див. Json-io (http://code.google.com/p/json-io/). Він серіалізує об’єктний графік Java в JSON і десеріалізується з нього. Він обробляє всі об’єкти Java, з або без публічних конструкторів, Serializeable чи не Serializable тощо. Цей самий код траверсу буде основою для зовнішньої реалізації "equals ()" та external "hashcode ()". До речі, JsonReader / JsonWriter (json-io) зазвичай швидший, ніж вбудований ObjectInputStream / ObjectOutputStream.

Цей JsonReader / JsonWriter можна використовувати для порівняння, але він не допоможе з хеш-кодом. Якщо вам потрібно універсальний хеш-код () і дорівнює (), йому потрібен власний код. Можливо, мені вдасться вирішити це із загальним відвідувачем графіків. Побачимо.

Інші міркування - статичні поля - це просто - їх можна пропустити, тому що всі еквівалентні екземпляри () мали б однакове значення для статичних полів, оскільки статичні поля поділяються у всіх екземплярах.

Щодо перехідних полів - це буде вибір. Іноді ви можете хотіти, щоб перехідні періоди рахували інший раз. "Іноді ти відчуваєш себе горіхом, іноді - ні."

Поверніться до проекту json-io (для інших моїх проектів), і ви знайдете проект зовнішніх рівних () / хеш-код (). Я ще не маю назви цього, але це буде очевидно.

Apache щось дає, перетворити обидва об'єкти в рядки та порівняти рядки, але вам доведеться переосмислити toString ()

obj1.toString().equals(obj2.toString())

Заміна наString ()

Якщо всі поля примітивні типи:

import org.apache.commons.lang3.builder.ReflectionToStringBuilder;
@Override
public String toString() {return 
ReflectionToStringBuilder.toString(this);}

Якщо у вас є непримітивні поля та / або колекція та / або карта:

// Within class
import org.apache.commons.lang3.builder.ReflectionToStringBuilder;
@Override
public String toString() {return 
ReflectionToStringBuilder.toString(this,new 
MultipleRecursiveToStringStyle());}

// New class extended from Apache ToStringStyle
import org.apache.commons.lang3.builder.ReflectionToStringBuilder;
import org.apache.commons.lang3.builder.ToStringStyle;
import java.util.*;

public class MultipleRecursiveToStringStyle extends ToStringStyle {
private static final int    INFINITE_DEPTH  = -1;

private int                 maxDepth;

private int                 depth;

public MultipleRecursiveToStringStyle() {
    this(INFINITE_DEPTH);
}

public MultipleRecursiveToStringStyle(int maxDepth) {
    setUseShortClassName(true);
    setUseIdentityHashCode(false);

    this.maxDepth = maxDepth;
}

@Override
protected void appendDetail(StringBuffer buffer, String fieldName, Object value) {
    if (value.getClass().getName().startsWith("java.lang.")
            || (maxDepth != INFINITE_DEPTH && depth >= maxDepth)) {
        buffer.append(value);
    } else {
        depth++;
        buffer.append(ReflectionToStringBuilder.toString(value, this));
        depth--;
    }
}

@Override
protected void appendDetail(StringBuffer buffer, String fieldName, 
Collection<?> coll) {
    for(Object value: coll){
        if (value.getClass().getName().startsWith("java.lang.")
                || (maxDepth != INFINITE_DEPTH && depth >= maxDepth)) {
            buffer.append(value);
        } else {
            depth++;
            buffer.append(ReflectionToStringBuilder.toString(value, this));
            depth--;
        }
    }
}

@Override
protected void appendDetail(StringBuffer buffer, String fieldName, Map<?, ?> map) {
    for(Map.Entry<?,?> kvEntry: map.entrySet()){
        Object value = kvEntry.getKey();
        if (value.getClass().getName().startsWith("java.lang.")
                || (maxDepth != INFINITE_DEPTH && depth >= maxDepth)) {
            buffer.append(value);
        } else {
            depth++;
            buffer.append(ReflectionToStringBuilder.toString(value, this));
            depth--;
        }
        value = kvEntry.getValue();
        if (value.getClass().getName().startsWith("java.lang.")
                || (maxDepth != INFINITE_DEPTH && depth >= maxDepth)) {
            buffer.append(value);
        } else {
            depth++;
            buffer.append(ReflectionToStringBuilder.toString(value, this));
            depth--;
        }
    }
}}

Я думаю, ви це знаєте, але теоретично ви повинні завжди переоцінювати .equals, щоб стверджувати, що два об'єкти справді рівні. Це означає, що вони перевіряють замінені методи .equals на своїх членів.

Така річ, чому .equals визначено в Object.

Якби це робилося послідовно, у вас не виникло б проблем.

Гарантія зупинки для такого глибокого порівняння може бути проблемою. Що слід робити наступним чином? (Якщо ви реалізуєте такий компаратор, це зробило б хороший одиничний тест.)

LinkedListNode a = new LinkedListNode();
a.next = a;
LinkedListNode b = new LinkedListNode();
b.next = b;

System.out.println(DeepCompare(a, b));

Ось ще:

LinkedListNode c = new LinkedListNode();
LinkedListNode d = new LinkedListNode();
c.next = d;
d.next = c;

System.out.println(DeepCompare(c, d));

Я думаю, що найпростіше рішення, натхнене рішенням Рея Хулхи, - це серіалізувати об'єкт і потім глибоко порівняти необроблений результат.

Серіалізація може бути як байт, json, xml або простий toString і т. Д. ToString, здається, дешевше. Lombok генерує для нас безкоштовний легко налаштований ToSTring. Дивіться приклад нижче.

@ToString @Getter @Setter
class foo{
    boolean foo1;
    String  foo2;        
    public boolean deepCompare(Object other) { //for cohesiveness
        return other != null && this.toString().equals(other.toString());
    }
}   

Так як Java 7 Objects.deepEquals(Object, Object).