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
Encapsulation with properties allows us to change how object's attributes are implemented behind the scenes.
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
Looking back over the code
we've just written,
0:00
I can see some improvements we could make.
0:02
The first thing I see is
that we have two lines
0:05
that are identical to each other here.
0:08
A common saying coders use
is keep your code dry.
0:11
Dry stands for don't repeat yourself.
0:14
Having duplicate or
0:17
even similar code like this is one
example of what's known as a code smell.
0:18
A code smell is something in the code that
indicates that there's a potential problem
0:23
with how the software is designed.
0:27
Let's look at why having these
duplicate lines might be a problem for
0:29
us and then see how we can fix it.
0:32
Let's take a closer look at these lines.
0:35
In both lines,
0:37
the location property is being set to the
location on the path at this _pathStep.
0:38
In the case of constructor
the _pathStep is zero.
0:43
And in the move method, the _pathStep
is just the next step on the path.
0:47
In either case,
0:52
the location property is being set to
reflect where the invader is on the path.
0:53
So whenever _pathStep changes,
the location must also change.
0:59
This can be problematic as
we add more to this class.
1:04
You see, these two places might not be
the only places we'll want to change
1:07
the _pathStep in the future.
1:11
If we ever add code that
touches the _pathStep field,
1:13
we'll need to be sure
to update the location.
1:16
What if someone who doesn't
know this code as well as we do
1:19
wants to make some changes?
1:22
They'll need to know this very
obscure piece of information.
1:24
So the root cause of this code smell
is that we have a property that must be
1:27
updated every time another field changes.
1:31
We can fix this by computing
the location every time it's requested,
1:34
instead of storing it every time
the _pathStep field changes.
1:38
This is a good solution, so
1:42
long as computing the new location
isn't a really expensive operation.
1:43
We know that computing the new location is
just an array lookup inside the path class
1:48
and array lookups are not
expensive operations.
1:52
To do this, we need to introduce
the idea of a computed property.
1:55
A computed property is a property
that doesn't wrap an actual field.
2:00
Remember, this property, as it's
written right now is really a field,
2:04
a getter method and a setter method.
2:08
Let me rewrite this property so that it's
computed each time the getter is called.
2:11
So we'll get rid of the setter.
2:16
And now expand this property a little bit.
2:20
Now in here, we'll just return
the location that the invader's at,
2:25
given the _pathStep.
2:29
We no longer need to update
the location anymore.
2:48
Now, no matter what _pathStep is set to or
when and where it's set, the location
2:52
property will always accurately
reflect the location of the invader.
2:57
Now instead having a property
that’s a field, a getter and
3:02
a setter, we now have what looks
a lot more like a simple method.
3:05
In fact, we could have coded
this up as a method too.
3:09
But this is actually a very good case for
a computed property, though.
3:13
You see, the user of this class doesn't
need to know that the location property is
3:16
actually computed from the _path and
_pathStep fields.
3:21
All they need to know is that they
can type invader.location and
3:24
get the location of
the invader on the map.
3:28
This is an implementation
detail that's best hidden.
3:31
And because we did proper encapsulation
with access modifiers and
3:33
properties, we were able to make
this change without changing
3:36
anything about the way this
class is used by others.
3:40
It can sometimes be difficult to decide
whether to write a property or a method.
3:44
There is sometimes a tendency to turn
every method that doesn't have parameters
3:49
into a computed property.
3:52
Properties intentionally look like fields
because they should be used like fields.
3:55
They should do simple things
related to getting and
3:59
setting data that's stored in the object.
4:02
That's a general guideline for deciding
whether to write a property or a method.
4:04
There's also an expectation when using
a property that it's going to be
4:08
a reasonably inexpensive operation and
return quickly.
4:12
Just keep this in mind when writing
properties and you'll be all right.
4:16
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