Preview
Video Player
00:00
00:00
Using Static Methods
5:33Let's use what we learned about static methods and the Math class to finish coding up the DistanceTo method.
Now that we know how to use the static
square root method in the math class,
0:00
let's use it to finish coding up
the DistanceTo method, in the Point class.
0:04
The last thing we needed to do to
complete the Cartesian distance formula,
0:08
is to add these two values together and
take the square root.
0:13
We can actually do that
in a single statement.
0:17
We can say Math.Sqrt of
xDiffSquared + yDiffSquared.
0:21
There we go.
0:32
We've coded up the cartesian
distance formula.
0:33
Now we just need to return the result.
0:36
Let's test our method in main.
0:41
Let's clear out this code and
then get the distance between
0:43
this point at (4, 2) and
the coordinates at (5,
0:49
5) and
print the result using console.rightline.
0:54
Now let's open the console to compile and
run this.
1:02
Looks like we got a compiler error.
1:13
It says the name Math does not
exist in the current context.
1:15
And this is back in the point.cs file,
line 22.
1:18
So let's go back there.
1:22
I see.
1:25
We forgot to add the using System.
1:25
All right.
1:34
Let's run this again.
1:35
Here's another compiler error.
1:38
It says cannot implicitly
convert type double to int.
1:39
And this is in point.cs, line twenty four.
1:44
Again they're Math.Sqrt.
1:50
This error must be saying that
it can't convert the double
1:54
that's returned from
Math.Sqrt to an integer.
1:57
Remember that the documentation for
Math.Sqrt said it returns a double?
2:01
This is one of those rare times when
we don't care about the decimal value
2:06
of the result.
2:10
We're only using whole
numbers in our game.
2:12
An invader can't be halfway
between two grid squares.
2:15
Truncating the decimal value
we get from this formula
2:19
gives us the correct
distance in discrete units.
2:21
Remember that when we cast
a double to an integer
2:25
it removes the decimal
portion of the value.
2:27
This is called truncation.
2:30
And that's what we want to do.
2:32
So we can just type int.
2:34
in parentheses here to
get the desired effect.
2:35
This will cast the result
of Math.Sqrt to an integer.
2:39
Now let's save, compile and run again.
2:43
All right so we see the result is three.
2:48
So the distance between point (4,
2) and coordinate (5,5) is 3.
2:51
If you like, you can verify on
a calculator that this is correct.
2:55
Let's take a final look at
the DistanceTo method before we move on.
3:01
There are five lines in
the DistanceTo method.
3:06
It might surprise you to hear that we
could have written all this in a single
3:10
line of code.
3:13
Let me type it here
underneath the existing code.
3:15
Then we can talk about why we might
prefer one way over the other.
3:18
So the cartesian distance
formula is the square root
3:22
Of the sum of the square for this.
3:31
We use another method in the math
class called POW for power.
3:38
This allows us to raise
a value to a power.
3:42
In this case, two.
3:45
So we have the square root of
the sum of the squared differences.
3:56
So we get X minus x and
Y minus y so this code here,
4:02
does the exact same thing
as this code up here.
4:09
As you can see it puts the entire
math formula on a single line.
4:17
One advantage of putting
the code all in the same line,
4:22
is that it gets rid of
most of the variables.
4:25
The fewer variables there are,
4:27
the less likely you are to type
the wrong one in the wrong place.
4:29
Say, for example,
that I typed xDiff here instead of yDiff.
4:34
>> That's a very common
mistake when programming.
4:40
Because the variables look so similar,
it's not obvious what the problem is.
4:43
Just because you can put all the code on
a single line, doesn't mean you should.
4:48
In fact, this is actually
a good approach to programming.
4:52
You see, by coding it this way,
4:57
we've broken up the solution into smaller
parts that are easier to think about.
4:59
Solutions that are easier to
think about are easier to code.
5:03
Once you think you have
a correct solution implemented,
5:08
you can test it with known values.
5:12
After you verify that the solution is
correct, you can always go back and
5:14
refactor the code into
a less verbose form.
5:18
Then run the same tests again to verify
that the changes didn't break anything.
5:21
This is a very common pattern for
designing, refactoring, optimizing and
5:26
refining software.
5:31