Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
An encapsulation strategy is to only allow indirect access to fields with getter and setter accessor methods.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
So far,
the invader class is completely empty.
0:04
We can start to code it up now.
0:08
One attribute the invader should
have is its location on the map.
0:10
We need this in order to determine
how close they are to towers,
0:14
to see if they're in range of each other.
0:17
Let's add a MapLocation field to
the invader class and call it Location.
0:20
It'll need to be public so the other
classes can get the invader's location.
0:26
And it can't be read only because
the location changes throughout the game.
0:30
Generally it's a bad idea
to make fields public
0:34
because this exposes too much of
the internal workings of the class.
0:37
In other words,
this is poor encapsulation.
0:41
A better way to go is to make
the Location field private and
0:44
then write public methods
to access the field.
0:48
We'll need two methods.
0:51
One that gets the location and
one that sets the location.
0:53
This pattern is so common in programming
that there are special terms for
0:57
these kinds of methods.
1:01
They're called accessor methods.
1:03
The method that's used to get
the value is called a getter.
1:05
And the method that's used to set
the value is called a setter.
1:09
We'll call the getter GetLocation.
1:12
So I'll say public and
1:15
it will return our MapLocation
cuz that's the type of the field.
1:17
And we'll call it GetLocation.
1:22
And it won't take any parameters because
all it's doing is getting the value
1:27
of the location field and
inside here we'll just return location.
1:33
And I need to change this to underscore
1:40
lowercase l because now
this is a private field.
1:43
For the setter, we'll say public void
because it won't return anything.
1:47
And we'll call it SetLocation and
1:53
it will take a MapLocation
as its parameter.
1:57
And we'll call that value.
2:01
And it will set the value of
_location to the value passed in.
2:07
Now we have a getter and
a setter for the location field.
2:13
At this point you're probably wondering
why we wrote these two methods
2:16
instead of just making
the location field public.
2:19
There are a number of reasons for
using getters and setters.
2:22
For one, it makes it possible to add
code associated with reading and
2:25
writing this field.
2:30
We can now add code inside of these
methods that will be executed
2:31
every time another class attempts
to read or write the location.
2:35
Say for example that we wanted to
make sure that the value parameter
2:39
meets certain conditions before
we change the value of location.
2:43
Or we might want to return something
other than what's stored in location
2:47
under certain conditions.
2:52
Having these methods also
makes debugging much easier.
2:54
There are special programs called
debuggers which we'll learn about
2:57
more in future courses.
3:01
Debuggers can be used to pause
the program before a line is executed.
3:02
The catch is that the line
must be executable.
3:07
Not all lines of code
are considered executable.
3:11
Returning location and assigning location
are both executable lines of code.
3:15
The location field all by
itself is not executable.
3:21
It just represents a place
to store information.
3:26
The line of code we tell the debugger
to stop at is called a breakpoint.
3:29
We can't set a breakpoint
at the location field.
3:33
But, having these two methods gives us
two convenient breakpoint opportunities
3:36
that we wouldn't have if we had
made location a public field.
3:41
A third reason for using getters and
setters is to future-proof the code.
3:45
I know it's hard to imagine right now, but
3:49
someday we might need to change
something about the location field.
3:52
For example, maybe we don't want
the location to be stored in this class.
3:56
We might move it to another class
that this class in turn uses.
4:00
If we were to make a change like that,
4:05
we'd have to fix every other class that
was directly accessing the location field.
4:07
That we wouldn't even have the ability
to fix those other classes
4:12
because they're maintained by other
people who we don't even know.
4:15
There are a few really good reasons for
using getters and
4:20
setters instead of public fields.
4:22
We'll learn more about these reasons
only after we've learned the other two
4:25
principles of object oriented programming,
abstraction and polymorphism.
4:28
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up