When overriding Object.Equals, is it appropriate to use the passed in object's Equals(MyType)?

Question

For a simple example, assume you have two classes that are different in many ways, but can still be considered "equateable":

class WholeNumber: IEquatable<WholeNumber> {
    int value;

    public override bool Equals(object obj) {
        if (obj is IEquatable<WholeNumber>) {
            IEquatable<WholeNumber> other = (IEquatable<WholeNumber>) obj;
            return other.Equals(this);
        } else {
            return false;
        }
    }

    public bool Equals(WholeNumber other) {
        return this.value == other.value;
    }
}

class Fraction : IEquatable<WholeNumber> {
    WholeNumber numerator;
    WholeNumber denominator;

    public bool Equals(WholeNumber other) {
        if (denominator != 1) {
            // Assume fraction is already reduced
            return false;
        } else {
            return this.numerator.Equals(other);
        }
    }
}

This will allow any object that claims to be equateable to WholeNumber to be passed into the WholeNumber's Equals(object) function and get the desired result without WholeNumber needed to know about any other class.

Is this pattern a good idea? Is using IEquatable with other classes a common (where it makes sence) thing to do?

Answer 1

No, this is a bad idea. While infinite recursion does not happen with this code, it is a constant threat when you have some instances of Equals() delegating to others. (If you use this approach then I'd strongly suggest writing many unit tests to make sure that Equals() does what you expect in all cases.)

Note that when a.Equals((object)b) returns true, a.GetHashCode() == b.GetHashCode() must also be true. If you cannot ensure that new WholeNumber(2) and new Fraction(2, 4) have the same hash code, then they should not compare as equal by Equals(object).

The practice I have adopted is that the Equals(object) override only returns true if the argument's type is or derives from the type where the override is declared -- in this case, obj is WholeNumber. If this is true but obj.GetType() != typeof(WholeNumber) then I do call b.Equals(a) so that the more-derived Equals() gets priority.

If you need equality with cousin types, then that is where IEquatable<T> comes in. In this case you would implement IEquatable<Fraction> on WholeNumber too, and it would make perfect sense to delegate to Fraction's implementation of IEquatable<WholeNumber>.Equals() to avoid duplicating that logic. (Providing an implicit conversion from WholeNumber to Fraction might be beneficial here, too.)