Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I've been thinking about this question for a bit and after a bit of consideration I agree that implementing <code>IEquatable&lt;T&gt;</code> and <code>IComparable&lt;T&gt;</code> should only be done on sealed types. </p> <p>I went back and forth for a bit but then I thought of the following test. Under what circumstances should the following ever return false? IMHO, 2 objects are either equal or they are not. </p> <pre><code>public void EqualitySanityCheck&lt;T&gt;(T left, T right) where T : IEquatable&lt;T&gt; { var equals1 = left.Equals(right); var equals2 = ((IEqutable&lt;T&gt;)left).Equals(right); Assert.AreEqual(equals1,equals2); } </code></pre> <p>The result of <code>IEquatable&lt;T&gt;</code> on a given object should have the same behavior as <code>Object.Equals</code> assuming the comparer is of the equivalent type. Implementing <code>IEquatable&lt;T&gt;</code> twice in an object hierarchy allows for, and implies, there are 2 different ways of expressing equality in your system. It's easy to contrive any number of scenarios where <code>IEquatable&lt;T&gt;</code> and <code>Object.Equals</code> would differ since there are multiple <code>IEquatable&lt;T&gt;</code> implementations but only a single <code>Object.Equals</code>. Hence the above would fail and create a bit of confusion in your code. </p> <p>Some people may argue that implementing <code>IEquatable&lt;T&gt;</code> at a higher point in the object hierarchy is valid because you want to compare a subset of the objects properties. In that case you should favor an <code>IEqualityComparer&lt;T&gt;</code> which is specifically designed to compare those properties. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload