correttamente implementare il confronto di due oggetti di tipo diverso ma semanticamente equivalenti

Question

ho trovato una domanda simile

How to compare two distinctly different objects with similar properties

che possono implicitamente e/o in parte, una risposta alla mia domanda.

Supponiamo che io voglio confrontare (senza un sacco di condizioni nidificate) questo oggetto:

class ObjectA { 
    public string PropertyX { get; set; } 
    public char PropertyY { get; set; } 
    public long PropertyZ { get; set; } 
} 

ad un System.String. Sono interessato solo a uguaglianza o disuguaglianza (non un intervallo di valori sull'identità).

L'implementazione di IEquatable<string> in ObjectA è una scelta appropriata? Non mi interessa cosa semplicemente funziona, voglio identificare il modello corretto per tale caso.

Come altre informazioni, si prega di considerare che ObjectA sarà spesso fornito come sequenza di IEnumerable<ObjectA>.

Non ho bisogno di sapere se "string"== o !=objectA istanza; l'ordinamento non è coinvolto.

Modifica per chiarire (e aiuto)

Ci dispiace, ma scrivere una buona domanda è a volte difficile ...

Supponiamo che non posso rappresentare ObjectA come stringa a scopo di confronto (violare l'incapsulamento non è un'opzione).

• In context-1 Devo corrispondere a PropertyY.

• In context-2 devo confrontarlo con un algoritmo applicato a PropertyY/PropertyZ.

@Oliver soluzione alla fine della domanda mi aiuta ancora (e di nuovo 1). posso semplicemente definire un'interfaccia personalizzata:

interface IContextConverter { 
    string ToEquatableStringForContext1(); 
    string ToEquatableStringForContext2(); 
} 

dal momento che ho anche un ObjectB con stessa logica, ma diverse proprietà, entrambi saranno implementare IContextConverter (o forse trovare un nome migliore) evitando di violare RAP.

Answer 1

consiglio vivamente a non implementare IEquatable<string>, causare soprattutto quando si lavora con le collezioni , dizionari, LINQ, ecc. non sai davvero quando uno di questi metodi sarà chiamato da qualche parte nel profondo che porta forse a bug sottili.

A causa del fatto che ti piace confrontare due oggetti di diverso tipo, un semplice Comparer<T> non funziona anche.

Quindi o scrivere TypeConverter che converte l'oggetto nel tipo desiderato (nel caso di un string) o aggiungere un metodo all'oggetto come .ToEquatableString() e utilizzare la loro produzione di confrontare l'oggetto con l'altra stringa.

Ecco un esempio su di voi potrebbe ottenere tutti gli elementi, che corrispondono a uno di una stringa in un'altra raccolta:

IEnumerable<String> otherElements = new[] {"abc", "def", "ghi" }; 
IEnumerable<ObjectA> myObjects = GetObjects(); 

var matchesFound = otherElements.Join(// Take the first collection. 
       myObjects, // Take the second collection. 
       s => s, // Use the elements in the first collection as key (the string). 
       obj => obj.ToEquatableString(), // Create a string from each object for comparison. 
       (s, obj) => obj, // From the matching pairs take simply the objects found. 
       StringComparer.OrdinalIgnoreCase); // Use a special string comparer if desired. 

Answer 2

NOTA: Non raccomando particolarmente questa soluzione per questo caso particolare, ma ho spesso utilizzato questo framework per implementare Value Equality per le strutture. I trade-off difficili sono comuni nel nostro campo e le risposte che si rivolgono a quelle, accompagnate da opportuni avvertimenti, sembrano in ordine.

Suppongo che desideri progettare la semantica di Value Equality sulla tua classe nello stesso modo in cui .NET framework fa ciò per la classe string.Come minimo, quanto segue è necessario:

public override bool Equals(object obj) { 
    return (obj is ObjectA) && this == (ObjectA)obj; 
} 
bool IEquatable<ObjectA>.Equals(ObjectA rhs) { 
    return this == rhs; 
} 
public static bool operator != (ObjectA lhs, ObjectA rhs) { 
    return ! (lhs == rhs); 
} 
public static bool operator == (ObjectA lhs, ObjectA rhs) { 
    return (lhs.PropertyX == rhs.PropertyX); 
} 
public override int GetHashCode() { 
    return PropertyX.GetHashCode() 
} 

espansione per consentire il confronto di valore beween Objecta e stringa:

bool IEquatable<ObjectA>.Equals(string rhs) { 
    return this == rhs; 
} 
public static bool operator != (ObjectA lhs, string rhs) { 
    return ! (lhs == rhs); 
} 
public static bool operator != (string lhs, ObjectA rhs) { 
    return ! (lhs == rhs); 
} 
public static bool operator == (ObjectA lhs, string rhs) { 
    return (lhs.PropertyX == rhs); 
} 
public static bool operator == (string lhs, ObjectA rhs) { 
    return (lhs == rhs.PropertyX); 
} 

Answer 3

ci sono molte possibilità.

Se ti senti un ObjectA è una sorta di System.String, si potrebbe scrivere una conversione definita dall'utente (implicita o esplicita) ObjectA-System.String, o System.String-ObjectA, o entrambe le direzioni.

È inoltre possibile sovraccaricare gli operatori == e != con una firma come operator ==(ObjectA oa, string s). Fai attenzione che c'è differenza tra oa == s e s == oa.

Una di queste due possibilità può causare confusione. Sarebbe anche confuso sovrascrivere il virtuale Equals(object) o introdurre un sovraccarico Equals(string). Pertanto non consiglio l'implementazione di IEquatable<string>.

Perché non scrivere semplicemente un metodo con un nome non utilizzato, ad esempio public bool EqualsString(string s)? Quindi dovrai chiamare questo metodo in modo esplicito, ovviamente, ma ciò porterà a una minore confusione. Un'altra idea sarebbe quella di utilizzare un costruttore della firma public ObjectA(string s) e quindi implementare l'uguaglianza "omogenea" di ObjectA e ObjectA.