Question

Is there any other reason for implementing an hash code function for my types other than allowing for good use of hash tables?

Let’s say I am designing some types that I intend to use internally. I know that types are “internal” to the system, and I also know I will never use those types in hash tables. In spite of this, I decide I will have to redefine the equals() method.

Theory says I should also redefine the hash code method, but I can’t see any reason why, in this case, I should do it.

Can anyone point me out any other reason?

This question can be rephrased to : in which situations should we implement a hash code method in our types.

PS : I am not asking how to implement one. I am asking when.

Answer 1

You might not – but will any of your code, for example, use LINQ? There are a number of unexpected places that might use a hashmap or dictionary on your data.

If you don’t want unexpected… “fun”, then if you change Equals, override GetHashCode. Likewise, any IEquatable<T>.Equals should match the object.Equals implementation.