[MUSIC]

So far, the invader class is completely empty.

We can start to code it up now.

One attribute the invader should have is its location on the map.

We need this in order to determine how close they are to towers,

to see if they're in range of each other.

Let's add a MapLocation field to the invader class and call it Location.

It'll need to be public so the other classes can get the invader's location.

And it can't be read only because the location changes throughout the game.

Generally it's a bad idea to make fields public

because this exposes too much of the internal workings of the class.

In other words, this is poor encapsulation.

A better way to go is to make the Location field private and

then write public methods to access the field.

We'll need two methods.

One that gets the location and one that sets the location.

This pattern is so common in programming that there are special terms for

these kinds of methods.

They're called accessor methods.

The method that's used to get the value is called a getter.

And the method that's used to set the value is called a setter.

We'll call the getter GetLocation.

So I'll say public and

it will return our MapLocation cuz that's the type of the field.

And we'll call it GetLocation.

And it won't take any parameters because all it's doing is getting the value

of the location field and inside here we'll just return location.

And I need to change this to underscore

lowercase l because now this is a private field.

For the setter, we'll say public void because it won't return anything.

And we'll call it SetLocation and

it will take a MapLocation as its parameter.

And we'll call that value.

And it will set the value of _location to the value passed in.

Now we have a getter and a setter for the location field.

At this point you're probably wondering why we wrote these two methods

instead of just making the location field public.

There are a number of reasons for using getters and setters.

For one, it makes it possible to add code associated with reading and

writing this field.

We can now add code inside of these methods that will be executed

every time another class attempts to read or write the location.

Say for example that we wanted to make sure that the value parameter

meets certain conditions before we change the value of location.

Or we might want to return something other than what's stored in location

under certain conditions.

Having these methods also makes debugging much easier.

There are special programs called debuggers which we'll learn about

more in future courses.

Debuggers can be used to pause the program before a line is executed.

The catch is that the line must be executable.

Not all lines of code are considered executable.

Returning location and assigning location are both executable lines of code.

The location field all by itself is not executable.

It just represents a place to store information.

The line of code we tell the debugger to stop at is called a breakpoint.

We can't set a breakpoint at the location field.

But, having these two methods gives us two convenient breakpoint opportunities

that we wouldn't have if we had made location a public field.

A third reason for using getters and setters is to future-proof the code.

I know it's hard to imagine right now, but

someday we might need to change something about the location field.

For example, maybe we don't want the location to be stored in this class.

We might move it to another class that this class in turn uses.

If we were to make a change like that,

we'd have to fix every other class that was directly accessing the location field.

That we wouldn't even have the ability to fix those other classes

because they're maintained by other people who we don't even know.

There are a few really good reasons for using getters and

setters instead of public fields.

We'll learn more about these reasons only after we've learned the other two

principles of object oriented programming, abstraction and polymorphism.