Jaka jest różnica między IEquatable a po prostu przesłanianiem Object.Equals ()?

Chcę, aby moja Foodklasa mogła testować, ilekroć jest ona równa innej instancji Food. Później użyję go na liście i chcę użyć jego List.Contains()metody. Czy powinienem zaimplementować IEquatable<Food>czy po prostu zastąpić Object.Equals()? Z MSDN:

Ta metoda określa równość za pomocą domyślnego modułu porównującego równość zdefiniowanego przez obiektową implementację metody IEquatable.Equals dla T (typ wartości na liście).

Moje następne pytanie brzmi: z jakich funkcji / klas środowiska .NET korzystają Object.Equals()? Czy powinienem go używać?

Głównym powodem jest wydajność. Kiedy leki generyczne zostały wprowadzone w .NET 2.0 były one w stanie dodać kilka zgrabnych klas takich jak List<T>, Dictionary<K,V>, HashSet<T>, itd. Struktury te w ogromnym stopniu korzystają z GetHashCodei Equals. Ale dla typów wartości wymagało to boksowania. IEquatable<T>pozwala strukturze wdrożyć silnie typowaną Equalsmetodę, więc nie jest wymagane boksowanie. Dzięki temu znacznie lepsza wydajność przy użyciu typów wartości z kolekcjami ogólnymi.

Typy referencyjne nie odnoszą tak dużych korzyści, ale IEquatable<T>implementacja pozwala uniknąć rzutowania, z System.Objectktórego może mieć znaczenie, jeśli jest często wywoływany.

Jak zauważono na blogu Jareda Parsona , nadal musisz zaimplementować przesłonięcia obiektów.

Według MSDN :

W przypadku zastosowania IEquatable<T>, należy również zastąpić implementacje bazowe klasowych Object.Equals(Object)i GetHashCode tak, że ich zachowanie jest zgodne z tym z IEquatable<T>.Equals metody. Jeśli to zrobisz Object.Equals(Object), twoja przesłonięta implementacja jest również wywoływana w wywołaniach Equals(System.Object, System.Object)metody static w twojej klasie. Zapewnia to, że wszystkie wywołania Equalsmetody zwracają spójne wyniki.

Wygląda więc na to, że nie ma żadnej rzeczywistej różnicy funkcjonalnej między tymi dwoma, z wyjątkiem tego, że można je wywołać w zależności od sposobu użycia klasy. Z punktu widzenia wydajności lepiej jest używać wersji ogólnej, ponieważ nie wiąże się z nią kara za boksowanie / rozpakowywanie.

Z logicznego punktu widzenia lepiej jest również wdrożyć interfejs. Przesłonięcie obiektu tak naprawdę nikomu nie mówi, że twoja klasa jest rzeczywiście dająca się porównać. Zastąpienie może być po prostu klasą nic nie rób lub płytką implementacją. Korzystanie z interfejsu wyraźnie mówi: „Hej, ta rzecz jest ważna do sprawdzania równości!” To po prostu lepszy projekt.

Rozszerzając to, co powiedział Josh, o praktyczny przykład. +1 do Josha - miałem już napisać to samo w mojej odpowiedzi.

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() { }
}

W ten sposób mam do ponownego użycia metodę Equals (), która działa od razu dla wszystkich moich klas pochodnych.

Jeśli zadzwonimy object.Equals, wymusza to kosztowne boksowanie według rodzajów wartości. Jest to niepożądane w scenariuszach wrażliwych na wydajność. Rozwiązaniem jest użyć IEquatable<T>.

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

Chodzi o IEquatable<T>to, że daje ten sam wynik, object.Equalsale szybciej. Ograniczenia where T : IEquatable<T>należy używać z typami ogólnymi, takimi jak poniżej.

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

w przeciwnym razie wiąże się z slower object.Equals().