Jaka jest różnica między IEqualityComparer <T> i IEquatable <T>?

Chcę zrozumieć scenariusze, w których IEqualityComparer<T>i IEquatable<T>należy je stosować. Dokumentacja MSDN dla obu wygląda bardzo podobnie.

IEqualityComparer<T>jest interfejsem dla obiektu, który przeprowadza porównanie dwóch obiektów tego typu T.

IEquatable<T>dotyczy obiektu typu, Taby mógł porównać się z innym obiektem tego samego typu.

Decydując się na użycie IEquatable<T>lub IEqualityComparer<T>, można zapytać:

Czy istnieje preferowany sposób testowania dwóch przypadków Trówności, czy też istnieje kilka równorzędnych sposobów?

• Jeśli istnieje tylko jeden sposób testowania dwóch wystąpień Trówności lub jeśli preferowana jest jedna z kilku metod, IEquatable<T>byłby to właściwy wybór: ten interfejs powinien być implementowany tylko Tsamodzielnie, tak aby jedna instancja Tmiała wewnętrzną wiedzę o jak porównać się z innym wystąpieniem T.

• Z drugiej strony, jeśli istnieje kilka równie rozsądnych metod porównywania dwóch Tdla równości, IEqualityComparer<T>wydaje się bardziej odpowiedni: Ten interfejs nie ma być implementowany Tsamodzielnie, ale przez inne „zewnętrzne” klasy. Dlatego podczas testowania dwóch instancji Trówności, ponieważ Tnie ma wewnętrznego zrozumienia równości, będziesz musiał dokonać wyraźnego wyboru IEqualityComparer<T>instancji, która przeprowadza test zgodnie z określonymi wymaganiami.

Przykład:

Rozważmy te dwa typy (które mają mieć semantykę wartości ):

interface IIntPoint : IEquatable<IIntPoint>
{
    int X { get; }
    int Y { get; }
}

interface IDoublePoint  // does not inherit IEquatable<IDoublePoint>; see below.
{
    double X { get; }
    double Y { get; }
}

Dlaczego tylko jeden z tych typów miałby dziedziczyć IEquatable<>, a drugi nie?

W teorii istnieje tylko jeden rozsądny sposób porównania dwóch wystąpień każdego typu: są one równe, jeśli właściwości Xi Yw obu przypadkach są równe. Zgodnie z tym myśleniem oba typy powinny wdrożyć IEquatable<>, ponieważ nie wydaje się prawdopodobne, że istnieją inne sensowne sposoby przeprowadzania testu równości.

Problem polega na tym, że porównywanie liczb zmiennoprzecinkowych pod kątem równości może nie działać zgodnie z oczekiwaniami z powodu drobnych błędów zaokrągleń . Istnieją różne metody porównywania liczb zmiennoprzecinkowych pod kątem niemal równości , z których każda ma określone zalety i kompromisy, i możesz chcieć samodzielnie wybrać, która metoda jest odpowiednia.

sealed class DoublePointNearEqualityComparerByTolerance : IEqualityComparer<IDoublePoint>
{
    public DoublePointNearEqualityComparerByTolerance(double tolerance) { … }
    …
    public bool Equals(IDoublePoint a, IDoublePoint b)
    {
        return Math.Abs(a.X - b.X) <= tolerance  &&  Math.Abs(a.Y - b.Y) <= tolerance;
    }
    …
}

Zauważ, że strona, do której odsyłam (powyżej), wyraźnie stwierdza, że ​​ten test bliskiej równości ma pewne słabości. Ponieważ jest to IEqualityComparer<T>implementacja, możesz ją po prostu zamienić, jeśli nie jest wystarczająco dobra do twoich celów.

Masz już podstawową definicję tego, czym one są . Krótko mówiąc, jeśli zaimplementujesz IEquatable<T>w klasie T, Equalsmetoda na obiekcie typu Tinformuje, czy sam obiekt (testowany pod kątem równości) jest równy innemu wystąpieniu tego samego typu T. Natomiast IEqualityComparer<T>służy do testowania równości dowolnych dwóch wystąpień T, zwykle poza zakresem wystąpień T.

Co do tego, do czego służą, może być początkowo mylące. Z definicji powinno być jasne, że stąd IEquatable<T>(zdefiniowana w Tsamej klasie ) powinna być de facto standardem reprezentacji unikalności jej obiektów / instancji. HashSet<T>, Dictionary<T, U>( GetHashCodebranie pod uwagę również jest nadpisywane), Containsna List<T>etc korzystają z tego. Wdrożenie IEqualityComparer<T>na Tnie pomaga powyższe ogólne przypadki. W związku z tym implementacja IEquatable<T>w innej klasie niż T. To:

class MyClass : IEquatable<T>

rzadko ma sens.

Z drugiej strony

class T : IEquatable<T>
{
    //override ==, !=, GetHashCode and non generic Equals as well

    public bool Equals(T other)
    {
        //....
    }
}

tak należy to zrobić.

IEqualityComparer<T>może być przydatne, gdy potrzebujesz niestandardowej weryfikacji równości, ale nie jako ogólna zasada. Na przykład, w Personpewnym momencie w klasie może być konieczne przetestowanie równości dwóch osób na podstawie ich wieku. W takim przypadku możesz:

class Person
{
    public int Age;
}

class AgeEqualityTester : IEqualityComparer<Person>
{
    public bool Equals(Person x, Person y)
    {
        return x.Age == y.Age;
    }

    public int GetHashCode(Person obj)
    {
        return obj.Age.GetHashCode;
    }
}

Aby je przetestować, spróbuj

var people = new Person[] { new Person { age = 23 } };
Person p = new Person() { age = 23 };

print people.Contains(p); //false;
print people.Contains(p, new AgeEqualityTester()); //true

Podobnie IEqualityComparer<T>na Tnie ma sensu.

class Person : IEqualityComparer<Person>

To prawda, że ​​to działa, ale nie wygląda dobrze dla oczu i podważa logikę.

Zwykle to, czego potrzebujesz IEquatable<T>. Idealnie byłoby, gdybyś miał tylko jeden, IEquatable<T>podczas gdy wiele IEqualityComparer<T>jest możliwych na podstawie różnych kryteriów.

IEqualityComparer<T>I IEquatable<T>są dokładnie analogiczne do Comparer<T>i IComparable<T>które są wykorzystywane do celów porównawczych zamiast zrównując; dobry wątek , w którym napisałem tę samą odpowiedź :)

IEqualityComparer jest używany, gdy równość dwóch obiektów jest implementowana zewnętrznie, np. Jeśli chcesz zdefiniować funkcję porównującą dla dwóch typów, dla których nie masz źródła, lub w przypadkach, w których równość między dwiema rzeczami ma sens tylko w pewnym ograniczonym kontekście.

IEquatable służy do zaimplementowania samego obiektu (tego, który jest porównywany pod kątem równości).

Jeden porównuje dwa Ts. Drugi może porównać się do innych T. Zwykle wystarczy użyć tylko jednego na raz, a nie obu.