Jonas: In the last lecture we implemented a new class
which showed us the need for encapsulation and data privacy.
So let's now tackle this very important principle
of object oriented programming.
Now first, remember that encapsulation basically means
to keep some properties and methods private inside the class
so that they are not accessible from outside of the class.
Then the rest of the methods are basically exposed
as a public interface, which we can also call API.
So this is essential to do in anything
more than a toy application.
Now, there are two big reasons why we need encapsulation
and data privacy.
So first it is to prevent code
from outside of a class to accidentally manipulate
or data inside the class.
And that's exactly what we did
by the end of the last lecture here.
So this is also the reason why
we implement a public interface.
So we are not supposed to manually mess with this property
and therefore we should encapsulate it.
Now, the second reason is
that when we expose only a small interface
so a small API consisting only of a few public methods
then we can change all the other internal methods
with more confidence.
Because in this case, we can be sure
that external code does not rely on these private methods.
And so therefore our code will not break
when we do internal changes.
So that's what encapsulation
and data privacy are and the reasons for it.
And so let's now actually implement it.
However JavaScript classes actually
do not yet support real data privacy and encapsulation.
Now there is a proposal to add truly private class fields
and methods to the language,
but it's not completely ready yet.
I will still show it to you in the next lecture
because it's really cool
but even when this feature ships in the browser
it will take some time until you can use it with confidence.
And so in this lecture, we will basically fake encapsulation
by simply using a convention.
So the first candidate to protect here is again,
this movements array that we have been talking about.
So the movements are mission critical data
and so here we will protect this data
so that no one can accidentally manipulate it.
And for now, all we will do is to add this underscore
in front of the property name and that's it.
Now we need to then go ahead and change it everywhere.
So that's here and yeah, that's actually it.
So again this does not actually make
the property truly private
because this is just a convention.
So it's something that developers agree to use
and then everyone does it this way.
But since it is not truly private we call this protected,
so protected property.
And so now if we wanted to get the movements outside here
we could, of course still do this.
So that's what I was just saying
which is that the data here is of course still accessible
if we use this underscore outside here as well
but at least now everyone on your team
and that includes yourself will know that this property
is not supposed to be touched outside of the class.
So you can still do it
but at least you will know that it is wrong, okay?
Now, if we still wanted to give access
to the movements array from the outside
then we would have to implement a public method for that.
So let's do that actually right here.
So let's say get movements.
And of course we could also create a getter here
instead of this method, but let's just keep it simple.
So it's very common to actually have a method
that is called get or set instead of using a real getter
or a real setter.
And so all that this will do
is to return this.movements.
And so now this would be
the correct way to get the movements, so get movements.
And so this one everyone
can still at least access the movements
but they cannot override them.
So they cannot set the movements
unless of course they use the underscore with the convention
but then at least they will know
that it's wrong to access the property.
Next, we could also protect here the pin.
So this is also something that doesn't make much sense
to be accessible from the outside.
And in fact, we could make everything protected here
but I think that like this, we are good to go.
So this is just a small example anyway.
And so for now, let's leave it like this.
To finish, let's just also protect
then the approved loan method.
So this one I also mentioned by the end
of the previous lecture.
So this is a method that is only
supposed to be internally by the bank.
Let's say basically just to check
if a loan should be approved.
So essentially this method here should not be part
of the public API, but all the others should be.
So right now we are protecting this method.
And so our public API right now consists
of these other four remaining methods, all right?
So this is how we protect fields from unwanted access.
Now, as I said, of course, developers need to know
about this convention and need to follow it
because otherwise everything will still be public.
But now in the next lecture, we're actually gonna talk
about truly private fields and methods.
And so with that, we will then fix this problem for good.