We Keep Coding

Why should GetHashCode implement the same logic as Equals?

In this MSDN page it says:
Warning:
If you override the GetHashCode method, you should also override Equals, and vice versa. If your overridden Equals method returns true when two objects are tested for equality, your overridden GetHashCode method must return the same value for the two objects.
I have also seen many similar recommendations and I can understand that when overriding the Equals method I would also want to override the GetHashCode. As far as I can work out though, the GetHashCode is used with hash table look-ups, which is not the same as equality checking.
Here is an example to help explain what I want to ask:
public class Temperature /* Immutable */
{
public Temperature(double value, TemperatureUnit unit) { ... }
private double Value { get; set; }
private TemperatureUnit Unit { get; set; }
private double GetValue(TemperatureUnit unit)
{
/* return value converted into the specified unit */
}
...
public override bool Equals(object obj)
{
Temperature other = obj as Temperature;
if (other == null) { return false; }
return (Value == other.GetValue(Unit));
}
public override int GetHashCode()
{
return Value.GetHashCode() + Unit.GetHashCode();
}
}
In this example, two Temperature objects are considered equal, even if they are not storing the same things internally (e.g. 295.15 K == 22 Celsius). At the moment the GetHashCode method will return different values for each. These two temperatures objects are equal but they are also not the same, so is it not correct that they have different hash codes?

When storing a value in a hash table, such as Dictionary<>, the framework will first call GetHashCode() and check if there's already a bucket in the hash table for that hash code. If there is, it will call .Equals() to see if the new value is indeed equal to the existing value. If not (meaning the two objects are different, but result in the same hash code), you have what's known as a collision. In this case, the items in this bucket are stored as a linked list and retrieving a certain value becomes O(n).
If you implemented GetHashCode() but did not implement Equals(), the framework would resort to using reference equality to check for equality which would result in every instance creating a collision.
If you implemented Equals() but did not implement GetHashCode(), you might run into a situation where you had two objects that were equal, but resulted in different hash codes meaning they'd maintain their own separate values in your hash table. This would potentially confuse anyone using your class.
As far as what objects are considered equal, that's up to you. If I create a hash table based on temperature, should I be able to refer to the same item using either its Celsius or Fahrenheit value? If so, they need to result in the same hash value and Equals() needs to return true.
Update:
Let's step back and take a look at the purpose of a hash code in the first place. Within this context, a hash code is used as a quick way to identify if two objects are most likely equal. If we have two objects that have different hash codes, we know for a fact they are not equal. If we have two objects that have the same hash code, we know they are most likely equal. I say most likely because an int can only be used to represent a few billion possible values, and strings can of course contain the complete works of Charles Dickens, or any number of possible values. Much in the .NET framework is based on these truths, and developers that use your code will assume things work in a way that is consistent with the rest of the framework.
If you were to have two instances that have different hash codes, but have an implementation of Equals() that returns true, you're breaking this convention. A developer that compares two objects might then use one of of those objects to refer to a key in a hash table and expect to get an existing value out. If all of a sudden the hash code is different, this code might result in a runtime exception instead. Or perhaps return a reference to a completely different object.
Whether 295.15k and 22C are equal within the domain of your program is your choice (In my opinion, they are not). However, whatever you decide, objects that are equal must return the same has code.

Warning:
If you override the GetHashCode method, you should also override Equals, and vice versa. If your overridden Equals method returns true when two objects are tested for equality, your overridden GetHashCode method must return the same value for the two objects.
This is a convention in the .NET libraries. It's not enforced at compile time, or even at run-time, but code in the .NET library (and likely any other external library) expects this statement to always be true:
If two object return true from Equals they will return the same hash code
And:
If two objects return different hash codes they are NOT equal
If you don't follow that convention, then your code will break. And worse it will probably break in ways that are really hard to trace (like putting two identical objects in a dictionary, or getting a different object from a dictionary than the one you expected).
So, follow the convention, or you will cause yourself a lot of grief.
In you particular class, you need to decide, either Equals returns false when the units are different, or GetHashCode returns the same hash code regardless of unit. You can't have it both ways.
So you either do this:
public override bool Equals(object obj)
{
Temperature other = obj as Temperature;
if (other == null) { return false; }
return (Value == other.Value && Unit == other.Unit);
}
Or you do this:
public override int GetHashCode()
{
// note that the value returned from ConvertToSomeBaseUnit
// should probably be cached as a private member
// especially if your class is supposed to immutable
return Value.ConvertToSomeBaseUnit().GetHashCode();
}
Note that nothing is stopping you from also implementing:
public bool TemperaturesAreEqual(Temperature other)
{
if (other == null) { return false; }
return (Value == other.GetValue(Unit));
}
And using that when you want to know if two temperatures represent the same physical temperature regardless of units.

Two objects that are equal should return the same HashCode (two objects that are different could return the same hashcode too, but that's a collision).
In your case, neither your equals nor your hashcode implementations are a good one. Problem being that the "real value" of the object is dependant on a parameter: there's no single property that defines the value of the object. You only store the initial unit to do equality compare.
So, why don't you settle on an internal definition of what's the Value of your Temperature?
I'd implement it like:
public class Temperature
{
public Temperature(double value, TemperatureUnit unit) {
Value = ConvertValue(value, unit, TemperatureUnit.Celsius);
}
private double Value { get; set; }
private double ConvertValue(double value, TemperatureUnit originalUnit, TemperatureUnit targetUnit)
{
/* return value from originalUnit converted to targetUnit */
}
private double GetValue(TemperatureUnit unit)
{
return ConvertValue(value, TemperatureUnit.Celsius, unit);
}
public override bool Equals(object obj)
{
Temperature other = obj as Temperature;
if (other == null) { return false; }
return (Value == other.Value);
}
public override int GetHashCode()
{
return Value.GetHashCode();
}
}
That way, your internal Value is what defines if two objects are the same, and is always expressed in the same unit.
You don't really care what Unit the object has: it makes no sense, since for getting the value back, you'll always pass a value. It only makes sense to pass it for the initial conversion.

What is the proper way to implement Equation functions [duplicate]

I'm having some difficulty using Linq's .Except() method when comparing two collections of a custom object.
I've derived my class from Object and implemented overrides for Equals(), GetHashCode(), and the operators == and !=. I've also created a CompareTo() method.
In my two collections, as a debugging experiment, I took the first item from each list (which is a duplicate) and compared them as follows:
itemListA[0].Equals(itemListB[0]); // true
itemListA[0] == itemListB[0]; // true
itemListA[0].CompareTo(itemListB[0]); // 0
In all three cases, the result is as I wanted. However, when I use Linq's Except() method, the duplicate items are not removed:
List<myObject> newList = itemListA.Except(itemListB).ToList();
Learning about how Linq does comparisons, I've discovered various (conflicting?) methods that say I need to inherit from IEquatable<T> or IEqualityComparer<T> etc.
I'm confused because when I inherit from, for example, IEquatable<T>, I am required to provide a new Equals() method with a different signature from what I've already overridden. Do I need to have two such methods with different signatures, or should I no longer derive my class from Object?
My object definition (simplified) looks like this:
public class MyObject : Object
{
public string Name {get; set;}
public DateTime LastUpdate {get; set;}
public int CompareTo(MyObject other)
{
// ...
}
public override bool Equals(object obj)
{
// allows some tolerance on LastUpdate
}
public override int GetHashCode()
{
unchecked
{
int hash = 17;
hash = hash * 23 + Name.GetHashCode();
hash = hash * 23 + LastUpdate.GetHashCode();
return hash;
}
}
// Overrides for operators
}
I noticed that when I inherit from IEquatable<T> I can do so using IEquatable<MyObject> or IEquatable<object>; the requirements for the Equals() signature change when I use one or the other. What is the recommended way?
What I am trying to accomplish:
I want to be able to use Linq (Distinct/Except) as well as the standard equality operators (== and !=) without duplicating code. The comparison should allow two objects to be considered equal if their name is identical and the LastUpdate property is within a number of seconds (user-specified) tolerance.
Edit:
Showing GetHashCode() code.

It doesn't matter whether you override object.Equals and object.GetHashCode, implement IEquatable, or provide an IEqualityComparer. All of them can work, just in slightly different ways.
1) Overriding Equals and GetHashCode from object:
This is the base case, in a sense. It will generally work, assuming you're in a position to edit the type to ensure that the implementation of the two methods are as desired. There's nothing wrong with doing just this in many cases.
2) Implementing IEquatable
The key point here is that you can (and should) implement IEquatable<YourTypeHere>. The key difference between this and #1 is that you have strong typing for the Equals method, rather than just having it use object. This is both better for convenience to the programmer (added type safety) and also means that any value types won't be boxed, so this can improve performance for custom structs. If you do this you should pretty much always do it in addition to #1, not instead of. Having the Equals method here differ in functionality from object.Equals would be...bad. Don't do that.
3) Implementing IEqualityComparer
This is entirely different from the first two. The idea here is that the object isn't getting it's own hash code, or seeing if it's equal to something else. The point of this approach is that an object doesn't know how to properly get it's hash or see if it's equal to something else. Perhaps it's because you don't control the code of the type (i.e. a 3rd party library) and they didn't bother to override the behavior, or perhaps they did override it but you just want your own unique definition of "equality" in this particular context.
In this case you create an entirely separate "comparer" object that takes in two different objects and informs you of whether they are equal or not, or what the hash code of one object is. When using this solution it doesn't matter what the Equals or GetHashCode methods do in the type itself, you won't use it.
Note that all of this is entirely unrelated from the == operator, which is its own beast.

The basic pattern I use for equality in an object is the following. Note that only 2 methods have actual logic specific to the object. The rest is just boiler plate code that feeds into these 2 methods
class MyObject : IEquatable<MyObject> {
public bool Equals(MyObject other) {
if (Object.ReferenceEquals(other, null)) {
return false;
}
// Actual equality logic here
}
public override int GetHashCode() {
// Actual Hashcode logic here
}
public override bool Equals(Object obj) {
return Equals(obj as MyObject);
}
public static bool operator==(MyObject left, MyObject right) {
if (Object.ReferenceEquals(left, null)) {
return Object.ReferenceEquals(right, null);
}
return left.Equals(right);
}
public static bool operator!=(MyObject left, MyObject right) {
return !(left == right);
}
}
If you follow this pattern there is really no need to provide a custom IEqualityComparer<MyObject>. The EqualityComparer<MyObject>.Default will be enough as it will rely on IEquatable<MyObject> in order to perform equality checks

You cannot "allow some tolerance on LastUpdate" and then use a GetHashCode() implementation that uses the strict value of LastUpdate!
Suppose the this instance has LastUpdate at 23:13:13.933, and the obj instance has 23:13:13.932. Then these two might compare equal with your tolerance idea. But if so, their hash codes must be the same number. But that will not happen unless you're extremely extremely lucky, for the DateTime.GetHashCode() should not give the same hash for these two times.
Besides, your Equals method most be a transitive relation mathematically. And "approximately equal to" cannot be made transitive. Its transitive closure is the trivial relation that identifies everything.

LINQ Distinct with EqualityComparer<T>.Default: IEquatable<T> implementation ignored?

I have a class Foo with two fields where the Equals and GetHashCode methods have been overridden:
public class Foo
{
private readonly int _x;
private readonly int _y;
public Foo(int x, int y) { _x = x; _y = y; }
public override bool Equals(object obj) {
Foo other = obj as Foo;
return other != null && _y == other._y;
}
public override int GetHashCode() { return _y; }
}
If I create an array of Foo:s and count the number of Distinct values of this array:
var array = new[] { new Foo(1, 1), new Foo(1, 2), new Foo(2, 2), new Foo(3, 2) };
Console.WriteLine(array.Distinct().Count());
The number of distinct values is recognized as:
2
If I now make my class Foo implement IEquatable<Foo> using the following implementation:
public bool Equals(Foo other) { return _y == other._y; }
The number of distinct values is still:
2
But if I change the implementation to this:
public bool Equals(Foo other) { return _x == other._x; }
The computed number of distinct Foo:s is neither 3 (i.e. the number of distinct _x) nor 2 (number of distinct _y), but:
4
And if I comment out the Equals and GetHashCode overrides but keep the IEquatable<Foo> implementation, the answer is also 4.
According to MSDN documentation, this Distinct overload should use the static property EqualityComparer.Default to define the equality comparison, and:
The Default property checks whether type T implements the System.IEquatable<T>
interface and, if so, returns an EqualityComparer<T> that uses that
implementation. Otherwise, it returns an EqualityComparer<T> that uses the
overrides of Object.Equals and Object.GetHashCode provided by T.
But looking at the experiment above, this statement does not seem to hold. At best, the IEquatable<Foo> implementation supports the already provided Equals and GetHashCode overrides, and at worst it completely corrupts the equality comparison.
My questions:
Why does the independent implementation of IEquatable<T> corrupt the equality comparison?
Can it play a role independent of the Equals and GetHashCode overrides?
If not, why does EqualityComparer<T>.Default look for this implementation first?

Your GetHashCode method only depends on y. That means if your Equals method doesn't depend on y, you've broken the contract of equality... they're inconsistent.
Distinct() is going to expect that equal elements have the same hash code. In your case, the only equal elements by x value have different hash codes, therefore Equals won't even get called.
From the docs of IEquatable<T>.Equals:
If you implement Equals, you should also override the base class implementations of Object.Equals(Object) and GetHashCode so that their behavior is consistent with that of the IEquatable<T>.Equals method.
Your implementation of Equals(Foo) isn't consistent with either Equals(object) or GetHashCode.
EqualityComparer<T>.Default will still delegate to your GetHashCode method - it will just use your Equals(T) method in preference to your Equals(object) method.
So to answer your questions in order:
Why does the independent implementation of IEquatable<T> corrupt the equality comparison?
Because you've introduced an inconsistent implementation. It's not meant to be independent in terms of behaviour. It's just meant to be more efficient by avoiding a type check (and boxing, for value types).
Can it play a role independent of the Equals and GetHashCode overrides?
It should be consistent with Equals(object) for the sake of sanity, and it must be consistent with GetHashCode for the sake of correctness.
If not, why does EqualityComparer<T>.Default look for this implementation first?
To avoid runtime type checking and boxing/unboxing, primarily.

Implemeting GetHashCode and Equals methods for ValueObjects

There is a passage from NHibernate documentation:
Note: if you define an ISet of composite elements, it is very important to implement Equals() and GetHashCode() correctly.
What does correctly mean there? Is it neccessary to implement those methods for all value objects in domain?
EXTENDING MY QUESTION
In the article Marc attached user Albic states:
It's actually very hard to implement GetHashCode() correctly because, in addition to the rules Marc already mentioned, the hash code should not change during the lifetime of an object. Therefore the fields which are used to calculate the hash code must be immutable.
I finally found a solution to this problem when I was working with NHibernate. My approach is to calculate the hash code from the ID of the object. The ID can only be set though the constructor so if you want to change the ID, which is very unlikely, you have to create a new object which has a new ID and therefore a new hash code. This approach works best with GUIDs because you can provide a parameterless constructor which randomly generates an ID.
I suddenly realized what I've got inside my AbstractEntity class:
public abstract class AbstractEntity<T> where T : AbstractEntity<T> {
private Nullable<Int32> hashCode;
public virtual Guid Id { get; protected set; }
public virtual Byte[] Version { get; set; }
public override Boolean Equals(Object obj) {
var other = obj as T;
if(other == null) {
return false;
}
var thisIsNew = Equals(this.Id, Guid.Empty);
var otherIsNew = Equals(other.Id, Guid.Empty);
if(thisIsNew && otherIsNew) {
return ReferenceEquals(this, other);
}
return this.Id.Equals(other.Id);
} // public override Boolean Equals(Object obj) {
public override Int32 GetHashCode() {
if(this.hashCode.HasValue) {
return this.hashCode.Value;
}
var thisIsNew = Equals(this.Id, Guid.Empty);
if(thisIsNew) {
this.hashCode = base.GetHashCode();
return this.hashCode.Value;
}
return this.Id.GetHashCode();
} // public override Int32 GetHashCode() {
public static Boolean operator ==(AbstractEntity<T> l, AbstractEntity<T> r) {
return Equals(l, r);
}
public static Boolean operator !=(AbstractEntity<T> l, AbstractEntity<T> r) {
return !Equals(l, r);
}
} // public abstract class AbstractEntity<T>...
As all components are nested within entities should I then implement Equals() and GetHashCode() for them?

Correctly means that GetHashCode returns the same hash code for the entities that are expected to be equal. Because equality of 2 entities is made by comparison of that code.
On the other side, that means that for entities that are not equal, the uniqueness of hash code has to be guaranteed, as much as it possible.

The documentation for Equals and GetHashCode explain this well and include specific guidance on implementation for value objects. For value objects, Equals is true if the objects are the same type and the public and private fields are equal. However, this explanation applies to framework value types and you are free to create your own Equals by overriding it.
GetHashCode has two rules that must be followed:
If two objects compare as equal, the GetHashCode method for each object must return the same value. However, if two objects do not
compare as equal, the GetHashCode methods for the two object do not
have to return different values.
The GetHashCode method for an object must consistently return the same hash code as long as there is no modification to the object state
that determines the return value of the object's Equals method. Note
that this is true only for the current execution of an application,
and that a different hash code can be returned if the application is
run again.

Should IEquatable<T>, IComparable<T> be implemented on non-sealed classes?

Anyone have any opinions on whether or not IEquatable<T> or IComparable<T> should generally require that T is sealed (if it's a class)?
This question occurred to me since I'm writing a set of base classes intended to aid in the implementation of immutable classes. Part of the functionality which the base class is intended to provide is automatic implementation of equality comparisons (using the class's fields together with attributes which can be applied to fields to control equality comparisons). It should be pretty nice when I'm finished - I'm using expression trees to dynamically create a compiled comparison function for each T, so the comparison function should be very close to the performance of a regular equality comparison function. (I'm using an immutable dictionary keyed on System.Type and double check locking to store the generated comparison functions in a manner that's reasonably performant)
One thing that has cropped up though, is what functions to use to check equality of the member fields. My initial intention was to check if each member field's type (which I'll call X) implements IEquatable<X>. However, after some thought, I don't think this is safe to use unless X is sealed. The reason being that if X is not sealed, I can't know for sure if X is appropriately delegating equality checks to a virtual method on X, thereby allowing a subtype to override the equality comparison.
This then brings up a more general question - if a type is not sealed, should it really implement these interfaces AT ALL?? I would think not, since I would argue that the interfaces contract is to compare between two X types, not two types which may or may not be X (though they must of course be X or a subtype).
What do you guys think? Should IEquatable<T> and IComparable<T> be avoided for unsealed classes? (Also makes me wonder if there is an fxcop rule for this)
My current thought is to have my generated comparison function only use IEquatable<T> on member fields whose T is sealed, and instead to use the virtual Object.Equals(Object obj) if T is unsealed even if T implements IEquatable<T>, since the field could potentially store subtypes of T and I doubt most implementations of IEquatable<T> are designed appropriately for inheritance.

I've been thinking about this question for a bit and after a bit of consideration I agree that implementing IEquatable<T> and IComparable<T> should only be done on sealed types.
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.
public void EqualitySanityCheck<T>(T left, T right) where T : IEquatable<T> {
var equals1 = left.Equals(right);
var equals2 = ((IEqutable<T>)left).Equals(right);
Assert.AreEqual(equals1,equals2);
}
The result of IEquatable<T> on a given object should have the same behavior as Object.Equals assuming the comparer is of the equivalent type. Implementing IEquatable<T> 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 IEquatable<T> and Object.Equals would differ since there are multiple IEquatable<T> implementations but only a single Object.Equals. Hence the above would fail and create a bit of confusion in your code.
Some people may argue that implementing IEquatable<T> 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 IEqualityComparer<T> which is specifically designed to compare those properties.

I would generally recommend against implementing IEquatable<T> on any non-sealed class, or implementing non-generic IComparable on most, but the same cannot be said for IComparable<T>. Two reasons:
There already exists a means of comparing objects which may or may not be the same type: Object.Equals. Since IEquatable<T> does not include GetHashCode, its behavior essentially has to match that of Object.Equals. The only reason for implementing IEquatable<T> in addition to Object.Equals is performance. IEquatable<T> offers a small performance improvement versus Object.Equals when applied to sealed class types, and a big improvement when applied to structure types. The only way an unsealed type's implementation of IEquatable<T>.Equals can ensure that its behavior matches that of a possibly-overridden Object.Equals, however, is to call Object.Equals. If IEquatable<T>.Equals has to call Object.Equals, any possible performance advantage vanishes.
It is sometimes possible, meaningful, and useful, for a base class to have a defined natural ordering involving only base-class properties, which will be consistent through all subclasses. When checking two objects for equality, the result shouldn't depend upon whether one regards the objects as being a base type or a derived type. When ranking objects, however, the result should often depend upon the type being used as the basis for comparison. Derived-class objects should implement IComparable<TheirOwnType> but should not override the base type's comparison method. It is entirely reasonable for two derived-class objects to compare as "unranked" when compared as the parent type, but for one to compare above the other when compared as the derived type.
Implementation of non-generic IComparable in inheritable classes is perhaps more questionable than implementation of IComparable<T>. Probably the best thing to do is allow a base-class to implement it if it's not expected that any child class will need some other ordering, but for child classes not to reimplement or override parent-class implementations.

Most Equals implementations I've seen check the types of the objects being compared, if they aren't the same then the method returns false.
This neatly avoids the problem of a sub-type being compared against it's parent type, thereby negating the need for sealing a class.
An obvious example of this would be trying to compare a 2D point (A) with a 3D point (B): for a 2D the x and y values of a 3D point might be equal, but for a 3D point, the z value will most likely be different.
This means that A == B would be true, but B == A would be false. Most people like the Equals operators to be commutative, to checking types is clearly a good idea in this case.
But what if you subclass and you don't add any new properties? Well, that's a bit harder to answer, and possibly depends on your situation.

I have stumbled over this topic today when reading
https://blog.mischel.com/2013/01/05/inheritance-and-iequatable-do-not-mix/
and I agree, that there are reasons not to implement IEquatable<T>, because chances exist that it will be done in a wrong way.
However, after reading the linked article I tested my own implementation which I use on various non-sealed, inherited classes, and I found that it's working correctly.
When implementing IEquatable<T>, I referred to this article:
http://www.loganfranken.com/blog/687/overriding-equals-in-c-part-1/
It gives a pretty good explanation what code to use in Equals(). It does not address inheritance though, so I tuned it myself. Here's the result.
And to answer the original question:
I don't say that it should be implemented on non-sealed classes, but I say that it definitely could be implemented without problems.
//============================================================================
class CBase : IEquatable<CBase>
{
private int m_iBaseValue = 0;
//--------------------------------------------------------------------------
public CBase (int i_iBaseValue)
{
m_iBaseValue = i_iBaseValue;
}
//--------------------------------------------------------------------------
public sealed override bool Equals (object i_value)
{
if (ReferenceEquals (null, i_value))
return false;
if (ReferenceEquals (this, i_value))
return true;
if (i_value.GetType () != GetType ())
return false;
return Equals_EXEC ((CBase)i_value);
}
//--------------------------------------------------------------------------
public bool Equals (CBase i_value)
{
if (ReferenceEquals (null, i_value))
return false;
if (ReferenceEquals (this, i_value))
return true;
if (i_value.GetType () != GetType ())
return false;
return Equals_EXEC (i_value);
}
//--------------------------------------------------------------------------
protected virtual bool Equals_EXEC (CBase i_oValue)
{
return i_oValue.m_iBaseValue == m_iBaseValue;
}
}
//============================================================================
class CDerived : CBase, IEquatable<CDerived>
{
public int m_iDerivedValue = 0;
//--------------------------------------------------------------------------
public CDerived (int i_iBaseValue,
int i_iDerivedValue)
: base (i_iBaseValue)
{
m_iDerivedValue = i_iDerivedValue;
}
//--------------------------------------------------------------------------
public bool Equals (CDerived i_value)
{
if (ReferenceEquals (null, i_value))
return false;
if (ReferenceEquals (this, i_value))
return true;
if (i_value.GetType () != GetType ())
return false;
return Equals_EXEC (i_value);
}
//--------------------------------------------------------------------------
protected override bool Equals_EXEC (CBase i_oValue)
{
CDerived oValue = i_oValue as CDerived;
return base.Equals_EXEC (i_oValue)
&& oValue.m_iDerivedValue == m_iDerivedValue;
}
}
Test:
private static void Main (string[] args)
{
// Test with Foo and Fooby for verification of the problem.
// definition of Foo and Fooby copied from
// https://blog.mischel.com/2013/01/05/inheritance-and-iequatable-do-not-mix/
// and not added in this post
var fooby1 = new Fooby (0, "hello");
var fooby2 = new Fooby (0, "goodbye");
Foo foo1 = fooby1;
Foo foo2 = fooby2;
// all false, as expected
bool bEqualFooby12a = fooby1.Equals (fooby2);
bool bEqualFooby12b = fooby2.Equals (fooby1);
bool bEqualFooby12c = object.Equals (fooby1, fooby2);
bool bEqualFooby12d = object.Equals (fooby2, fooby1);
// 2 true (wrong), 2 false
bool bEqualFoo12a = foo1.Equals (foo2); // unexpectedly "true": wrong result, because "wrong" overload is called!
bool bEqualFoo12b = foo2.Equals (foo1); // unexpectedly "true": wrong result, because "wrong" overload is called!
bool bEqualFoo12c = object.Equals (foo1, foo2);
bool bEqualFoo12d = object.Equals (foo2, foo1);
// own test
CBase oB = new CBase (1);
CDerived oD1 = new CDerived (1, 2);
CDerived oD2 = new CDerived (1, 2);
CDerived oD3 = new CDerived (1, 3);
CDerived oD4 = new CDerived (2, 2);
CBase oB1 = oD1;
CBase oB2 = oD2;
CBase oB3 = oD3;
CBase oB4 = oD4;
// all false, as expected
bool bEqualBD1a = object.Equals (oB, oD1);
bool bEqualBD1b = object.Equals (oD1, oB);
bool bEqualBD1c = oB.Equals (oD1);
bool bEqualBD1d = oD1.Equals (oB);
// all true, as expected
bool bEqualD12a = object.Equals (oD1, oD2);
bool bEqualD12b = object.Equals (oD2, oD1);
bool bEqualD12c = oD1.Equals (oD2);
bool bEqualD12d = oD2.Equals (oD1);
bool bEqualB12a = object.Equals (oB1, oB2);
bool bEqualB12b = object.Equals (oB2, oB1);
bool bEqualB12c = oB1.Equals (oB2);
bool bEqualB12d = oB2.Equals (oB1);
// all false, as expected
bool bEqualD13a = object.Equals (oD1, oD3);
bool bEqualD13b = object.Equals (oD3, oD1);
bool bEqualD13c = oD1.Equals (oD3);
bool bEqualD13d = oD3.Equals (oD1);
bool bEqualB13a = object.Equals (oB1, oB3);
bool bEqualB13b = object.Equals (oB3, oB1);
bool bEqualB13c = oB1.Equals (oB3);
bool bEqualB13d = oB3.Equals (oB1);
// all false, as expected
bool bEqualD14a = object.Equals (oD1, oD4);
bool bEqualD14b = object.Equals (oD4, oD1);
bool bEqualD14c = oD1.Equals (oD4);
bool bEqualD14d = oD4.Equals (oD1);
bool bEqualB14a = object.Equals (oB1, oB4);
bool bEqualB14b = object.Equals (oB4, oB1);
bool bEqualB14c = oB1.Equals (oB4);
bool bEqualB14d = oB4.Equals (oB1);
}