Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed C# Objects!
You have completed C# Objects!
Preview
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