2013-04-16 6 views
5

Perché non c'è un Objects.equal che riceve come argomento ogni tipo primitivo?Perché non ci sono guava Objects.equal (Object, Object) in tipi primitivi?

So che è possibile inserire il valore tramite #valueOf oppure lasciare che ogni primitiva sia autoboxata, ma non si perde prestazioni in questo modo? È qualcosa di cui mi stavo chiedendo da un po '.

Immaginate ho qualcosa di simile

public class Foo { 
    private final int integerValue; 
    private final boolean booleanValue; 
    private final Bar bar; 

    public Foo(int integerValue, boolean booleanValue, Bar bar) { 
     this.integerValue = integerValue; 
     this.booleanValue = booleanValue; 
     this.bar = bar; 
    } 

    @SuppressWarnings("boxing") 
    @Override 
    public boolean equals(Object object) { 
     if (object instanceof Foo) { 
      Foo that = (Foo) object; 

      return Objects.equal(this.integerValue, that.integerValue) 
        && Objects.equal(this.booleanValue, that.booleanValue) 
        && Objects.equal(this.bar, that.bar); 
     } 
     return false; 
    } 

    // hashCode implementation using guava also. 
} 

È questo il modo migliore per attuare equals? I valori primitivi saranno autoboxati, soffrendo (anche se è un po ') un degrado delle prestazioni. Potrei semplicemente usare lo == per loro, ma per me spezzerebbe il "flusso" di leggere il metodo degli uguali, rendendolo un po 'brutto. Quindi mi chiedo perché la lib di guava non abbia uno Objects.equal per ogni tipo primitivo. Qualcuno conosce la risposta?

EDIT

C'è per la MoreObjects.toStringHelper di sovraccarico per ogni primitivo (ma byte), che è una la ragione mi sono chiesto di non avere per Objects#equal. Inoltre, utilizzando l'argomento JB Nizet, sarebbe più sicuro il metodo equals perché è possibile modificare int per Integer senza doversi preoccupare della correttezza uguale.

Guava docs

+0

Informazioni sulla modifica: sembra che 'ToStringHelper' sia un membro di' Objects' perché tutte le istanze di 'Object' hanno' toString() 'in comune. Il fatto che l'helper stesso abbia argomenti 'int', ecc. È solo perché un' Object' potrebbe contenere un 'int' (da includere nel risultato' toString() '. Spero che abbia un senso. –

+0

ma se è perché potresti avere un campo 'int', lo stesso vale per' Objects # equal'. Sebbene sia diverso da 'Objects # equal', che può essere sostituito da' == ', non c'è nulla che tu possa usare in' StringHelper # add' per evitare l'autoboxing. Quindi, i metodi primitivi. O almeno è quello che penso: P –

risposta

6

ho potuto solo usare == per loro, ma per me si spezzerebbe il "flusso" di leggere il metodo equals, trasformandolo un po 'brutto.

Questo non è un motivo abbastanza convincente per aggiungere un sovraccarico di tale metodo per ogni tipo primitivo all'API di Guava: ogni metodo che un'esposizione API deve essere documentato, testato e gestito. Non ha senso quando l'unico vantaggio è l'estetica.

+2

+1, anche se direi che non è un "convincente * sufficiente * motivo." –

+0

Vedo il punto, ma spesso facciamo cose per rendere il codice più leggibile. Non è così, ma non so quanto sarebbe difficile mantenere questi metodi sovraccarichi (non un critico, davvero non so oltre al test e alla documentazione) –

+5

Il costo include ulteriore confusione nel Javadoc della classe 'Objects' per ogni utente che passa attraverso di esso cercando di trovare qualcosa, anche, per un beneficio abbastanza limitato (e discutibile). Inoltre, dovrei ammettere che troverei _realmente strano_ che ci sia una speciale gestione "uguale" per i tipi primitivi in ​​una classe chiamata 'Objects'. –

2

So che è possibile boxare il valore tramite #valueOf o lasciare che ogni primitiva sia autoboxata, ma non si perde prestazioni facendo questo?

Vero, ma per il codice sensibili alle prestazioni, si sarebbe sicuramente desidera utilizzare == comunque per ottenere un semplice if_icmpeq codice operativo anziché invocare un metodo. Pertanto, se stai utilizzando lo standard Objects.equal, probabilmente non stai scrivendo codice sensibile al rendimento e probabilmente non noterai il costo dell'autoboxing.

Non sto dicendo che una versione primitiva di Objects.equal avrebbe zero vantaggi, ma probabilmente non vale la pena di aggiungere diversi metodi alla libreria.

+0

ben inserito. Grazie per la risposta: D –

Problemi correlati