In the previous video,

we got this compiler warning when we overrode object.equals in the Point class.

TreehouseDefense.Point overrides Object.Equals but

it does not override Object.GetHashCode.

The hash code of an object is an integer that is unique to that object.

Different objects will have different hash codes.

Every object created is given a unique identifier.

So by default, this ID is used as an object's hash code.

This ID, if you will, is actually just its memory address.

Being able to identify an object by its hash code is very handy and

the GetHashCode method is used by many C# collection types.

An array is just one type of collection.

There are other types of collection classes that rely on being able to

identify an object using just an integer.

The most common collection that uses the GetHashCode method is .NET framework's

dictionary class.

A hash code is only an attempt to create a unique identifier for an object.

It is possible for two different objects to have the same hash code.

Just like my name is Jeremy but there are also other people named Jeremy.

In fact it's a rather common name.

If someone called out my name in a large crowd,

there's a good chance that more than one person would respond.

How could they know which person is the Jeremy they're looking for?

Well, they'd have to rely on more than just our name.

They'd probably need to get a look at each of us

in order to say which person they wanted.

This is why the methods Equals and GetHashCode go hand in hand.

If two objects map to the same hash code,

the only way to tell them apart is to check if they're equal.

Had we only overridden the GetHashCode method,

we'd get a similar compiler warning asking us to override Equals too.

Let's get a better idea of how the GetHashCode method works

by overriding it in Point.

So we'll type public

override int GetHashCode.

In order to implement GetHashCode, we need to make a couple decisions.

First if two objects are equal as we've defined equality to be up

here should their hash codes also be equal?

We almost always want this to be the case.

And this is what users of the GetHashCode method will expect.

Here we see that we determine if the Point objects are equal by comparing the X and

Y coordinates with each other.

We should also use X and Y when creating the new hash code.

But here's the problem that we always run into when creating hash codes.

We can only return a single integer as the hash code.

Here we have two integers, X and Y.

We can't return them both.

Let's say we just returned X as the hash code.

That means that all points with the same X value would have the same hash code.

That isn't very unique.

Our goal is to create a hash code that is unique as possible.

The best chance we have of doing this is by combining X and

Y, somehow, into a single integer.

There are lots of ways we could do this.

We could just add them together.

If X was five and Y was two we'd end up with a hash code of seven.

There are lots of ways to add two different integers together to get seven.

All of those points would also have the same hash code.

We could reduce those combinations by half just by multiplying X or

Y by a prime number before adding them together.

By doing this we're ensuring that X equals 5, and Y equals 2

gives us a different hash code than X equals 2 and Y equals 5.

So here we'll say return x

Times a relatively small prime number 31, and then add Y.

There are lots of ways to create hash codes, and

they are all compromises of some sort.

For what we're doing this is probably good enough.

I should mention that when computing hash codes it's best to compute them from

the hash codes of the fields that we're combining together.

This is because their hash codes are already fairly unique.

So we should write this as X.GetHashCode * 31 + Y.GetHashCode.

In the case of integers the result is the same since

the hash code of an integer is just its value.

So the hash code of five would be five.

If X and Y were of any other type it

would be important to call their GetHashCode methods.

This is just a good practice to always use GetHashCode when computing a hash code.

We'll learn more about how hash codes are used in other courses

where we use more advanced .NET collection types.