Esiste un'utilità di riflessione Java per eseguire un confronto approfondito di due oggetti?

Sto cercando di scrivere unit test per una varietà di clone()operazioni all'interno di un grande progetto e mi chiedo se esiste una classe esistente da qualche parte che è in grado di prendere due oggetti dello stesso tipo, fare un confronto profondo e dire se sei identico o no?

Unitils ha questa funzionalità:

Asserzione di uguaglianza attraverso la riflessione, con diverse opzioni come ignorare i valori predefiniti / nulli di Java e ignorare l'ordine delle raccolte

Amo questa domanda! Soprattutto perché non viene quasi mai risposto o risposto male. È come se nessuno l'avesse ancora capito. Territorio vergine :)

Prima di tutto, non pensare nemmeno all'utilizzo equals. Il contratto di equals, come definito nel javadoc, è una relazione di equivalenza (riflessiva, simmetrica e transitiva), non una relazione di uguaglianza. Per questo, dovrebbe anche essere antisimmetrico. L'unica implementazione di equalsciò è (o potrebbe mai essere) una vera relazione di uguaglianza è quella in java.lang.Object. Anche se hai usato equalsper confrontare tutto nel grafico, il rischio di rompere il contratto è piuttosto alto. Come ha sottolineato Josh Bloch in Effective Java , il contratto di uguaglianza è molto facile da rompere:

"Semplicemente non c'è modo di estendere una classe istanziabile e aggiungere un aspetto preservando il contratto uguale"

Inoltre, a cosa serve davvero un metodo booleano? Sarebbe bello incapsulare effettivamente tutte le differenze tra l'originale e il clone, non credi? Inoltre, presumo qui che tu non voglia essere disturbato dalla scrittura / manutenzione del codice di confronto per ogni oggetto nel grafico, ma piuttosto stai cercando qualcosa che si ridimensionerà con la fonte mentre cambia nel tempo.

Quindi, quello che vuoi veramente è una sorta di strumento di confronto statale. Il modo in cui questo strumento viene implementato dipende in realtà dalla natura del modello di dominio e dalle limitazioni delle prestazioni. Nella mia esperienza, non esiste una pallottola magica generica. E sarà lento per un gran numero di iterazioni. Ma per testare la completezza di un'operazione di clonazione, farà abbastanza bene il lavoro. Le tue due migliori opzioni sono la serializzazione e la riflessione.

Alcuni problemi che incontrerai:

• Ordine di raccolta: due raccolte devono essere considerate simili se contengono gli stessi oggetti, ma in un ordine diverso?
• Quali campi ignorare: transitori? Statico?
• Equivalenza del tipo: i valori dei campi devono essere esattamente dello stesso tipo? O va bene che uno estenda l'altro?
• C'è di più, ma dimentico ...

XStream è abbastanza veloce e combinato con XMLUnit farà il lavoro in poche righe di codice. XMLUnit è carino perché può segnalare tutte le differenze o semplicemente fermarsi alla prima che trova. E il suo output include l'xpath ai diversi nodi, il che è carino. Per impostazione predefinita, non consente raccolte non ordinate, ma può essere configurato per farlo. L'iniezione di un gestore delle differenze speciale (chiamato a DifferenceListener) consente di specificare il modo in cui si desidera gestire le differenze, incluso l'ignorare l'ordine. Tuttavia, non appena si desidera fare qualcosa oltre la più semplice personalizzazione, diventa difficile scrivere ei dettagli tendono ad essere legati a un oggetto di dominio specifico.

La mia preferenza personale è quella di utilizzare la riflessione per scorrere tutti i campi dichiarati e approfondire ciascuno di essi, monitorando le differenze man mano che procedo. Parola di avvertimento: non utilizzare la ricorsione a meno che non ti piacciano le eccezioni di overflow dello stack. Mantieni le cose nell'ambito con uno stack (usa un fileLinkedListo qualcosa). Di solito ignoro i campi transitori e statici e salto le coppie di oggetti che ho già confrontato, quindi non finisco in cicli infiniti se qualcuno decide di scrivere codice autoreferenziale (Tuttavia, confronto sempre i wrapper primitivi, non importa cosa , poiché gli stessi riferimenti oggetto vengono spesso riutilizzati). Puoi configurare le cose in anticipo per ignorare l'ordinamento della raccolta e per ignorare tipi o campi speciali, ma mi piace definire le mie politiche di confronto dello stato sui campi stessi tramite annotazioni. Questo, IMHO, è esattamente ciò a cui erano destinate le annotazioni, per rendere disponibili i metadati sulla classe in fase di esecuzione. Qualcosa di simile a:

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

Penso che questo sia in realtà un problema davvero difficile, ma totalmente risolvibile! E una volta che hai qualcosa che funziona per te, è davvero, davvero, utile :)

Quindi buona fortuna. E se ti viene in mente qualcosa di puro genio, non dimenticare di condividerlo!

Vedi DeepEquals e DeepHashCode () all'interno di java-util: https://github.com/jdereg/java-util

Questa classe fa esattamente ciò che l'autore originale richiede.

Sostituisci il metodo equals ()

Puoi semplicemente sovrascrivere il metodo equals () della classe utilizzando EqualsBuilder.reflectionEquals () come spiegato qui :

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

Dovevo solo implementare il confronto di due istanze di entità riviste da Hibernate Envers. Ho iniziato a scrivere il mio differire ma poi ho trovato il seguente framework.

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

Puoi confrontare due oggetti dello stesso tipo e mostrerà modifiche, aggiunte e rimozioni. Se non ci sono modifiche, gli oggetti sono uguali (in teoria). Vengono fornite annotazioni per i getter che dovrebbero essere ignorati durante il controllo. Il frame work ha applicazioni molto più ampie del controllo di uguaglianza, ovvero che sto usando per generare un registro delle modifiche.

Le sue prestazioni sono OK, quando si confrontano le entità JPA, assicurarsi di scollegarle prima dal gestore entità.

Sto usando 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();
}

In AssertJ , puoi fare:

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

Probabilmente non funzionerà in tutti i casi, tuttavia funzionerà in più casi che potresti pensare.

Ecco cosa dice la documentazione:

Asserire che l'oggetto in prova (effettivo) è uguale all'oggetto dato in base al confronto ricorsivo di una proprietà / campo per proprietà / campo (compresi quelli ereditati). Questo può essere utile se l'implementazione uguale a actual non ti soddisfa. Il confronto ricorsivo proprietà / campo non viene applicato ai campi che hanno un'implementazione di uguale personalizzato, ovvero verrà utilizzato il metodo uguale a sovrascritto invece di un campo per confronto di campo.

Il confronto ricorsivo gestisce i cicli. Per impostazione predefinita, i float vengono confrontati con una precisione di 1.0E-6 e raddoppia con 1.0E-15.

È possibile specificare un comparatore personalizzato per i campi (nidificati) o digitare rispettivamente usingComparatorForFields (Comparator, String ...) e usingComparatorForType (Comparator, Class).

Gli oggetti da confrontare possono essere di diversi tipi ma devono avere le stesse proprietà / campi. Ad esempio, se l'oggetto effettivo ha un nome String field, è previsto che anche l'altro oggetto ne abbia uno. Se un oggetto ha un campo e una proprietà con lo stesso nome, il valore della proprietà verrà utilizzato sul campo.

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 ha lo stesso MatcherPropertyValuesAs . Ma si basa sulla Convenzione JavaBeans (utilizza getter e setter). Se gli oggetti che devono essere confrontati non hanno getter e setter per i loro attributi, questo non funzionerà.

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
    }
}

Il bean utente - con getter e setter

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;
    }

}

Se i tuoi oggetti implementano Serializable puoi usare questo:

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);
    }
}

Il tuo esempio di elenco collegato non è così difficile da gestire. Quando il codice attraversa i due grafici degli oggetti, posiziona gli oggetti visitati in un Set o in una Mappa. Prima di passare a un altro riferimento a un oggetto, questo set viene testato per vedere se l'oggetto è già stato attraversato. Se è così, non c'è bisogno di andare oltre.

Sono d'accordo con la persona sopra che ha detto di usare un LinkedList (come uno Stack ma senza metodi sincronizzati su di esso, quindi è più veloce). Attraversare l'oggetto grafico utilizzando una pila, mentre si utilizza la riflessione per ottenere ogni campo, è la soluzione ideale. Scritto una volta, questo "esterno" equals () e "esterno" hashCode () è ciò che tutti i metodi equals () e hashCode () dovrebbero chiamare. Non avrai mai più bisogno di un metodo cliente uguale ().

Ho scritto un po 'di codice che attraversa un grafico a oggetti completo, elencato su Google Code. Vedi json-io (http://code.google.com/p/json-io/). Serializza un oggetto grafico Java in JSON e deserializzato da esso. Gestisce tutti gli oggetti Java, con o senza costruttori pubblici, Serializzabile o non Serializzabile, ecc. Questo stesso codice di attraversamento sarà la base per l'implementazione "equals ()" ed esterna "hashcode ()". A proposito, JsonReader / JsonWriter (json-io) è generalmente più veloce di ObjectInputStream / ObjectOutputStream incorporato.

Questo JsonReader / JsonWriter potrebbe essere utilizzato per il confronto, ma non aiuterà con il codice hash. Se vuoi un hashcode universale () e uguale (), ha bisogno del proprio codice. Potrei riuscire a farcela con un visitatore generico del grafico. Vedremo.

Altre considerazioni - campi statici - è facile - possono essere ignorati perché tutte le istanze equals () avrebbero lo stesso valore per i campi statici, poiché i campi statici sono condivisi tra tutte le istanze.

Per quanto riguarda i campi transitori, questa sarà un'opzione selezionabile. A volte potresti volere che i transienti contino altre volte no. "A volte ti senti un pazzo, a volte no."

Torna al progetto json-io (per i miei altri progetti) e troverai il progetto esterno equals () / hashcode (). Non ho ancora un nome, ma sarà ovvio.

Apache ti dà qualcosa, converti entrambi gli oggetti in stringa e confronta le stringhe, ma devi sovrascrivere aString ()

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

Sostituisci toString ()

Se tutti i campi sono tipi primitivi:

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

Se hai campi e / o collezione e / o mappa non primitivi:

// 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--;
        }
    }
}}

Immagino che tu lo sappia, ma in teoria dovresti sempre sovrascrivere .equals per affermare che due oggetti sono veramente uguali. Ciò implicherebbe che controllino i metodi .equals sostituiti sui loro membri.

Questo genere di cose è il motivo per cui .equals è definito in Object.

Se ciò fosse fatto in modo coerente, non avresti problemi.

Una garanzia ferma per un confronto così profondo potrebbe essere un problema. Cosa dovrebbe fare quanto segue? (Se si implementa un simile comparatore, questo sarebbe un buon test unitario.)

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

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

Eccone un altro:

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

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

Penso che la soluzione più semplice ispirata alla soluzione di Ray Hulha sia serializzare l'oggetto e quindi confrontare in profondità il risultato grezzo.

La serializzazione può essere byte, json, xml o semplice toString ecc. ToString sembra essere più economico. Lombok genera per noi ToSTring personalizzabili e gratuiti. Vedi esempio sotto.

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

Dal momento che Java 7, Objects.deepEquals(Object, Object).