¿Cuál es la diferencia entre IEqualityComparer <T> e IEquatable <T>?

Quiero entender los escenarios donde IEqualityComparer<T>y IEquatable<T>deberían usarse. La documentación de MSDN para ambos se ve muy similar.

IEqualityComparer<T>es una interfaz para un objeto que realiza la comparación en dos objetos del tipo T.

IEquatable<T>es para un objeto de tipo Tpara que pueda compararse con otro del mismo tipo.

Al decidir si usar IEquatable<T>o IEqualityComparer<T>, uno podría preguntar:

¿Existe una forma preferida de probar dos instancias de Tigualdad, o hay varias formas igualmente válidas?

• Si solo hay una forma de probar dos instancias de Tigualdad, o si se prefiere uno de varios métodos, entonces IEquatable<T>sería la elección correcta: se supone que esta interfaz se implementa solo por Tsí misma, de modo que una instancia de Ttiene conocimiento interno de cómo compararse con otra instancia de T.

• Por otro lado, si hay varios métodos igualmente razonables de comparar dos Ts para la igualdad, IEqualityComparer<T>parecería más apropiado: esta interfaz no debe implementarse por Tsí misma, sino por otras clases "externas". Por lo tanto, al probar dos instancias de Tigualdad, ya que Tno tiene una comprensión interna de la igualdad, tendrá que hacer una elección explícita de una IEqualityComparer<T>instancia que realice la prueba de acuerdo con sus requisitos específicos.

Ejemplo:

Consideremos estos dos tipos (que se supone que tienen una semántica de valor ):

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; }
}

¿Por qué solo uno de estos tipos heredaría IEquatable<>, pero no el otro?

En teoría, solo hay una manera sensata de comparar dos instancias de cualquier tipo: son iguales si las propiedades Xy Yen ambas instancias son iguales. De acuerdo con este pensamiento, ambos tipos deberían implementarse IEquatable<>, porque no parece probable que haya otras formas significativas de hacer una prueba de igualdad.

El problema aquí es que comparar números de coma flotante para la igualdad podría no funcionar como se esperaba, debido a errores de redondeo minucioso . Existen diferentes métodos para comparar números de punto flotante para casi la igualdad , cada uno con ventajas y compensaciones específicas, y es posible que desee poder elegir qué método es el adecuado.

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;
    }
    …
}

Tenga en cuenta que la página a la que me vinculé (arriba) declara explícitamente que esta prueba de casi igualdad tiene algunas debilidades. Como se trata de una IEqualityComparer<T>implementación, simplemente puede cambiarla si no es lo suficientemente buena para sus propósitos.

Ya tienes la definición básica de lo que son . En resumen, si implementa IEquatable<T>en clase T, el Equalsmétodo en un objeto de tipo Tle dice si el objeto mismo (el que se está probando para la igualdad) es igual a otra instancia del mismo tipo T. Mientras que, IEqualityComparer<T>es para probar la igualdad de dos instancias de T, típicamente fuera del alcance de las instancias de T.

En cuanto a lo que son, puede ser confuso al principio. A partir de la definición, debe quedar claro que, por lo tanto, IEquatable<T>(definido en la Tpropia clase ) debería ser el estándar de facto para representar la unicidad de sus objetos / instancias. HashSet<T>, Dictionary<T, U>(teniendo en GetHashCodecuenta que también se anula), Containsen List<T>etc. haga uso de esto. Implementar IEqualityComparer<T>en Tno ayuda a los casos generales mencionados anteriormente. Posteriormente, hay poco valor para implementar IEquatable<T>en cualquier otra clase que no sea T. Esta:

class MyClass : IEquatable<T>

Rara vez tiene sentido.

Por otra parte

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

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

así es como debe hacerse.

IEqualityComparer<T>puede ser útil cuando necesita una validación personalizada de igualdad, pero no como una regla general. Por ejemplo, en una clase de Personen algún momento, es posible que deba probar la igualdad de dos personas en función de su edad. En ese caso puedes hacer:

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;
    }
}

Para probarlos, intente

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

Del mismo modo IEqualityComparer<T>en Tque no tiene sentido.

class Person : IEqualityComparer<Person>

Es cierto que esto funciona, pero no se ve bien a los ojos y derrota la lógica.

Por lo general, lo que necesitas es IEquatable<T>. También, idealmente, puede tener solo uno, IEquatable<T>mientras que múltiples IEqualityComparer<T>es posible según diferentes criterios.

Los IEqualityComparer<T>y IEquatable<T>son exactamente análogos a Comparer<T>y IComparable<T>que se utilizan para fines de comparación en lugar de igualar; un buen hilo aquí donde escribí la misma respuesta :)

IEqualityComparer se utiliza cuando la igualdad de dos objetos se implementa externamente, por ejemplo, si desea definir un comparador para dos tipos para los que no tenía la fuente, o para los casos en que la igualdad entre dos cosas solo tiene sentido en un contexto limitado.

IEquatable es para el objeto en sí (el que se compara por igualdad) para implementar.

Uno compara dos Ts. El otro puede compararse con otros Ts. Por lo general, solo necesitará usar uno a la vez, no ambos.