Non-readonly fields referenced in GetHashCode()

问题:

Started with overriding concepts and I override the methods Equals and GetHashCode.

Primarily I came up with this "very simple code":

internal class Person
    {
        public string name;

        public int age;

        public string lname;

        public Person(string name, int age, string lname)
        {
            this.name = name;
            this.age = age;
            this.lname = lname;
        }

        public override bool Equals(object obj)
        {
            var person = obj as Person;
            if (person != null)
            {
                return person.age == this.age && person.name == this.name && person.lname == this.lname;
            }

            return false;
        }

        public override int GetHashCode()
        {
            return this.age.GetHashCode() * this.name.GetHashCode() * this.lname.GetHashCode();
        }
    }

While this works great, my "co-developer" Mr.Resharper gave me some suggestions:

1. Non-readonly fields referenced in GetHashCode(). Suggestions came in this line of code:

return this.age.GetHashCode() * this.name.GetHashCode() * this.lname.GetHashCode();

2. Should we use GetHashCode only for Properties?

回答1:

To summarise what was discussed in the comments:

Hashing is designed to provide a value that doesn't change for a given object, no matter what happens to it - hence it's best to depend only on readonly fields in your GetHashCode method.

Firstly, I would suggest making the name and lname field readonly, because they probably don't change in your usage scenario.

As for age, this is something that changes regularly, so probably best to store a DateTime for date of birth, which never changes. Then you can make that readonly too.

回答2:

If you change the value of a field, used in the hash calculation, after the object had been added to a hash based container like Dictionary or HashSet, you are essentially breaking the inner state of the container. Why is that? Because the object had been stored in a bucket corresponding to a hash value based on its initial state. When the state is changed, e.g. 'age' is modified, the object will continue to live in its old bucket in the hash container although this is not the correct bucket based on its current hash code. This can lead to pretty messy behaviour and a lot of headaches. I've written an article on this topic with some very specific examples, so you may want to check it out.