Why implement IEqualityComparer<T> in a separate class
why not implement it on the class itself?
Because it makes no sense. The whole purpose of the IEqualityComparer<T>
is to be implemented outside the type T
because it targets the "reason 1" from your post.
If you want the class itself to implement the equality logic, then you are expected to implement IEquatable<T>
which is provided specifically for such scenario, and EqualityComparer<T>.Default
will provide the necessary bridge to your implementation anytime IEqualityComparer<T>
is needed and not specified explicitly.
Since the class can provide only one hardcoded logic without any dynamic behavior and/or options, it's considered to be the default equality logic, hence the name of the static EqualityProvider<T>
property providing access to it.
IComparer<T>
as well as IEqualityComparer<T>
work with two instances of T so they have no need to be implemented as a part of T
class; however, implementing IEqualityComparer<T>
within the T
is a good practice, the scheme can be
public partial class Test {
private class TestComparer : IEqualityComparer<Test> {
public bool Equals(Test x, Test y) {
return x.id == y.id && x.date == y.date;
}
public int GetHashCode(Test obj) {
return obj.id.GetHashCode();
}
}
// Please, note "static"
public static IEqualityComparer<Test> MyTestComparer {get;} = new TestComparer();
public int id { get; set; }
public DateTime date { get; set; }
...
}
In this case you just use the comparer you want:
int distinctCountComparerClass = testList.Distinct(Test.MyTestComparer).Count();
Simply put, this way you can use different ways of comparing objects from the same class depending on the context.
It's basically inversion of control: it is not for the class itself to decide how another class might want to compare its instances.