Rappresentanza uguaglianza contro valore Uguaglianza

3

Sto codificando un sistema in cui ho oggetti che rappresentano un insieme di risorse. Queste risorse sono identificabili (hanno un ID). Può esistere una sola risorsa con lo stesso ID e quindi più oggetti con lo stesso ID dovrebbero avere gli stessi valori.
Il mio problema è con il concetto di uguaglianza in questo caso. Dovrebbe essere basato sull'ID o sui valori da solo? L'oggetto A = oggetto B perché ha lo stesso ID O dovrebbe oggetto A == oggetto B perché i loro campi sono gli stessi.

Una possibilità che stavo pensando era quella di avere il confronto basato su ID "uguale" e il confronto basato sul campo essere "equivalente". In alternativa potrei averlo in modo che il confronto basato sul campo fosse "uguale" e il confronto basato su ID era "representSameObject" (o qualcosa del genere). Solo un esempio di pseudo-codice:

class A {
   String uuid;
   int field1;
   double field2;
   List<String> listField;

   @Override
   public boolean equals(Object other) {
       return uuid.equals(other.uuid);
   }

   public boolean equivalent( other ) {
       if (this == other) {
           return true;
       }
       if (null == other) {
           return false;
       }
       if (other.getClass() != this.getClass()) {
           return false;
       }

       A rhs = (A) other;
       return new EqualsBuilder().append(field1, rhs.field1).append(field2, rhs.field2).append(listField, other.listField).isEquals();
   }
}

Alla fine questo può essere dovuto a una preferenza personale associata ai requisiti di sistema, ma sono molto interessato a scoprire come altri hanno affrontato questo concetto. È stato noioso da parte nostra da quando ho iniziato questo progetto!

Se fa la differenza, sto programmando al minuto in Java. Non mi importa da dove viene la risposta, anche se questo è ovviamente un problema concettuale.

    
posta Dennis 14.06.2013 - 13:14
fonte

3 risposte

1

Una cosa che puoi fare è guardare come i framework ORM, come Hibernate, gestiscono queste situazioni. Credo che per impostazione predefinita 'oggetti dominio' (oggetti che possono essere persistenti) ottengano un id e un equals() e hashCode() (che utilizzano l'id fornito per l'equivalenza) per impostazione predefinita.

Suggeriscono comunque che se si desidera utilizzare questi oggetti dominio nelle raccolte, è sempre necessario sovrascrivere i metodi equals() e hashCode() forniti.

Quindi forse è una questione di contesto. Credo che Hibernate usi gli id per vedere se ha già un oggetto persistente. Se l'id è nullo, proverà a fare un "inserimento" rispetto a se l'id non è nullo, proverà a cercare l'oggetto persistente e ad aggiornare i suoi campi. Se l'id non viene trovato, si tratta di una condizione di errore.

Spero che questa risposta ti indichi almeno in qualche direzione.

    
risposta data 14.06.2013 - 14:27
fonte
4

In realtà dovresti fare un ulteriore passo avanti e considerarlo un errore se ci sono due oggetti distinti che rappresentano entrambi la risorsa con ID X. Ciò significa che se hai due riferimenti all'oggetto per ID X, allora i due riferimenti dovrebbero essere uguali all'operatore == (che confronta l'uguaglianza di riferimento in Java).

Consentire a più oggetti di rappresentare una stessa risorsa comporta inevitabilmente il fatto che gli oggetti diventano fuori sincrono e bug perché diverse parti del sistema hanno viste differenti e incompatibili sullo stato della risorsa.

Inoltre, se utilizzi l'uguaglianza di riferimento come controllo dell'identità della risorsa, potresti utilizzare il metodo equals per verificare se due risorse hanno lo stesso valore in quel momento.

    
risposta data 14.06.2013 - 13:35
fonte
0

Se Bob ora indossa un cappello blu invece di un cappello rosso (quello che indossava ieri) è ancora Bob. Quindi cappello blu Bob è uguale a cappello rosso Bob.

Continuo a mantenere i miei pari a essere basati sull'identità. Se Bob è cambiato, tengo in un altro metodo o interfaccia.

    
risposta data 15.06.2013 - 03:34
fonte

Leggi altre domande sui tag