Was ist der Unterschied zwischen IEquatable und dem Überschreiben von Object.Equals ()?

Ich möchte, dass meine FoodKlasse testen kann, wann immer es einer anderen Instanz von entspricht Food. Ich werde es später für eine Liste verwenden, und ich möchte seine List.Contains()Methode verwenden. Soll ich implementieren IEquatable<Food>oder einfach überschreiben Object.Equals()? Von MSDN:

Diese Methode ermittelt die Gleichheit mithilfe des Standardgleichheitsvergleichs, der durch die Implementierung der IEquatable.Equals-Methode für T (den Wertetyp in der Liste) durch das Objekt definiert wird.

Meine nächste Frage lautet also: Welche Funktionen / Klassen des .NET Frameworks werden verwendet Object.Equals()? Soll ich es überhaupt benutzen?

Der Hauptgrund ist die Leistung. Wenn Generika in .NET 2.0 eingeführt wurden sie in der Lage waren , ein paar ordentlichen Klassen hinzuzufügen wie List<T>, Dictionary<K,V>, HashSet<T>usw. machen diese Strukturen starke Nutzung von GetHashCodeund Equals. Für Werttypen erforderte dies jedoch Boxen. IEquatable<T>Ermöglicht einer Struktur die Implementierung einer stark typisierten EqualsMethode, sodass kein Boxen erforderlich ist. Somit viel bessere Leistung bei Verwendung von Werttypen mit generischen Sammlungen.

Referenztypen profitieren nicht so sehr, aber mit der IEquatable<T>Implementierung können Sie eine Besetzung vermeiden, System.Objectdie einen Unterschied machen kann, wenn sie häufig aufgerufen wird.

Wie in Jared Parsons Blog erwähnt , müssen Sie die Objektüberschreibungen dennoch implementieren.

Laut MSDN :

Wenn Sie implementieren IEquatable<T>, sollten Sie auch die Basisklasse Implementierungen außer Kraft setzen Object.Equals(Object)und GetHashCode damit ihr Verhalten mit dem der konsistenten IEquatable<T>.Equals Methode. Wenn Sie überschreiben Object.Equals(Object), wird Ihre überschriebene Implementierung auch in Aufrufen der statischen Equals(System.Object, System.Object)Methode Ihrer Klasse aufgerufen . Dies stellt sicher, dass alle Aufrufe der EqualsMethode konsistente Ergebnisse liefern.

Es scheint also keinen wirklichen funktionalen Unterschied zwischen den beiden zu geben, außer dass beide aufgerufen werden könnten, abhängig davon, wie die Klasse verwendet wird. Unter Leistungsgesichtspunkten ist es besser, die generische Version zu verwenden, da damit keine Box- / Unboxing-Strafe verbunden ist.

Aus logischer Sicht ist es auch besser, die Schnittstelle zu implementieren. Das Überschreiben des Objekts sagt niemandem wirklich, dass Ihre Klasse tatsächlich gleichwertig ist. Die Überschreibung kann nur eine Do-Nothing-Klasse oder eine flache Implementierung sein. Über die Schnittstelle wird explizit gesagt: "Hey, dieses Ding ist für die Gleichheitsprüfung gültig!" Es ist einfach besseres Design.

Erweitern Sie das, was Josh gesagt hat, um ein praktisches Beispiel. +1 an Josh - Ich wollte das gleiche in meiner Antwort schreiben.

public abstract class EntityBase : IEquatable<EntityBase>
{
    public EntityBase() { }

    #region IEquatable<EntityBase> Members

    public bool Equals(EntityBase other)
    {
        //Generic implementation of equality using reflection on derived class instance.
        return true;
    }

    public override bool Equals(object obj)
    {
        return this.Equals(obj as EntityBase);
    }

    #endregion
}

public class Author : EntityBase
{
    public Author() { }
}

public class Book : EntityBase
{
    public Book() { }
}

Auf diese Weise habe ich eine wiederverwendbare Equals () -Methode, die für alle meine abgeleiteten Klassen sofort funktioniert.

Wenn wir anrufen object.Equals, zwingt es zu teurem Boxen auf Werttypen. Dies ist in leistungsabhängigen Szenarien unerwünscht. Die Lösung ist zu verwenden IEquatable<T>.

public interface IEquatable<T>
{
  bool Equals (T other);
}

Die Idee dahinter IEquatable<T>ist, dass es das gleiche Ergebnis liefert, object.Equalsaber schneller. Die Einschränkung where T : IEquatable<T>muss mit generischen Typen wie unten verwendet werden.

public class Test<T> where T : IEquatable<T>
{
  public bool IsEqual (T a, T b)
  {
    return a.Equals (b); // No boxing with generic T
  }
}

Andernfalls bindet es an slower object.Equals().