Okay, so it's time to start talking about Access Modifiers and
in particular private, public and protected as well as package private so
what we're going to do is Why you would want to restrict access to the field and
methods in your classes.
What we are going to do is implement a very simple and seriously flawed
bank account to demonstrated that and just before I go on one thing about the color
You've probably noticed if you've been following on, the last few videos have
been--look a little bit weird with some of the buttons and so forth not fitting.
There's currently an issue with 15, when you're trying to size up fonts, and for
some reason, when I select darkular, which is the dark theme, it doesn't happen, so.
I'm just gonna leave it in this mode now, let me know what you think of this and
I find it better to work in this mode but generally,
the white background is better for videos, but we'll see how we go with this anyway.
Okay so, first thing we wanna do is create a class.
We're gonna create a class called account so I'm just gonna do what we normally do.
Select the package and create a new class, and
call it Account OK, so that class is going to have, firstly, a string.
Private string account name.
So, it's still going to have a balance...actually,
what we're going to do...we'll change that to
a public, because we were talking about axis modifiers.
It's important to understand this, so We'll also make the balance zero.
That's also public, and public array list.
[NOISE] Array list,
integer, for transactions.
And transactions on the account, and then create a constructor.
And the constructor will accept the account name.
So we set the field account name to whatever's past,
and we also initialize the transactions.
So, this dot transactions equals new.
Array list integer so, so
it's just creating an empty array list ready for us to start adding records.
And, we also need a get R for the balance.
So, get R balance.
So, that's our basic counts class.
And, the, just to confirm the transactions, very, very basic.
What we're going to do is store the amounts as a positive number where it's
a deposit, and a negative number for withdraw, and put those in the right list.
Okay. So, next what we need is some methods
to support deposits and withdraws.
So what we're going to do is implement those and
then we're going to get the can't class to calculate the balance as well.
So firstly, the deposit, public_void deposit,
and pass a parameter of the amount I want to deposit.
We check if the amount > 0.
And if it is, we're going to add that transaction.add(amount) and
we also want to add that to the balance.
Now the balance gets incremented by the amount that pass this method.
And we'll put a message in the effect to say (amount + "deposited.
Balance is now") Plus this dot balance.
Else, what we're going to do, if it wasn't >0, we'll print out a message just to
say cannot deposit negative sums.
OK, so that's our very basic deposit method.
So let's now write the withdraw one.
Similar But obviously the money's coming out or
it's been deducting from the balance.
So public void withdraw, pass an amount as well.
Int withdrawal = -amount.
So converting it to a minus,
remember member because a negative number we're gonna assume is a withdrawal.
And I'll put if withdrawal is <0, you'll
start transactions dot add withdrawal,
and stop balance equals, we're adding withdrawal remembering it's gonna be
a minus number, we can still use a plus there.
And we can say amount [SOUND] withdrawn,
Balance is now, + this.balance.
Else, [SOUND] message,
Cannot withdraw Cannot withdraw on negative sums.
So that's our basic withdraw method.
Again it's checking, converting it to a minus because we're gonna pass a positive
amount and then we're setting it to a minus amount and
then we're checking to see if it's less than zero, which means we can withdraw.
We're gonna add that to the transactions,
bearing in mind a negative number we're considering to be withdraw.
We're adding the balance.
We're adding withdrawal, I should say to the balance comparing a minus,
it's going to be a minus number.
We can still do that and give a reflect to the updated balance and then updating and
how much is, you know, what the current balance is after the withdrawal, and
we're just showing an error message if there was a problem.
So, next, the last method we're going to create here.
It is going to be a bank like balance, a public void calculate dot,
so start with a balance of zero and we put four into I,
start transactions and we go through all the entries and list.
Now this .balance add to that,
bearing in mind that will work for plus or minus numbers.
And then we'll just print out a message to say, calculated balance is .balance.
Like I said.
So that's our method there.
Now for calculating the balance where we start on zero and we can go through and
tally up all the transactions.
To come up with what the balance is after all of those.
Okay, so to do some testing we're gonna go back to our main class and
then into our main method and we'll start with Account, then
we'll call it timsAccount = new Account
("Tim"), let's do some entry, do some transactions at timsAccount.
Deposit 1000, Tim's account withdrawal 500,
Tim's withdrawal minus 200,
Tim's account deposit Minus 20.
Some of these are obviously wrong, "timsAccount"
dot calculate balance,
and we'll print out a message.
Balance on account, account is past two down dot balance.
Very very straight forward as you can see there, text at the top pull out and
we will run this.
All right, you can see that we started out 1000 deposits, balance is now 1000,
500 withdrawn, bank is now 50,
we get an on the next line because we're trying to withdraw a negative sum.
And we can't deposit a negative sum either as you can see there.
So our calculated balance 500 which is correct.
And the balance account using the getter is also 500.
So everything works, and
probably in a real application, the withdraw and deposit methods would also
log somewhere to provide an auto-trailer activity on the account.
But notice that we've declared everything as public,
this is the thing I wanted to point out, so, go back to account.
You can see that everything's public, the account name, balance and
transactions and what that means is this allows any program using the account class
to modify the balance directly.
And we can do that by inserting the following code into main.
So, under this line here if I added another entry,
timsAccount.balance=5000 and run that
We've no changed the account balance, the balance on the account being 5,000.
Now, that's obviously not good being able to do that.
But, the bank would spot the attempt at fraud, by checking the transaction list.
Except we can also modify that as well.
So, we could do something like Tim's account dot transactions, dot add.
Forty-five hundred.
And we can do timsAccount dot calculate balance again.
So I can run that.
We now have a match you can see of the account balance but
also there's now an entry in the transaction ArrayList as well.
So, in a well designed system, the transactions list, in this case
the ArrayList Should only be modified by the deposit and withdrawal methods.
So by allowing access to the transactions list from outside the class and
the balance for that matter, we're introducing the potential for
errors in the program.
Or in this case, for fraud.
So obviously, here the fraud would be a deliberate act on the power of
a programmer but it's also the case that objects can be altered by mistake because
the implications of doing so.
Unapparent, in other words the programmer didn't really understand the ramifications
of what they are doing.
Point is if you expose fields of your classes, then anyone using the class
will reasonably assume that they can manipulate the values of those fields.
And because this bypasses the methods you've written to use those fields, as you
can see in this case, your classes may no longer behave as you intended them to.
So you may lose control over them.
So in other words, by making me count name balance and transaction fields public,
what we've done is we've allowed them to be modified outside of the account class.
And it's a simple fix, all we need to do is change them to public.
So, I'll come back here and change these to private.
Private, private.
So after we do that, we go back to main.
We actually now get errors as you can see on the screen, so
really the only way we can access those directly is by using in this case
the deposit and withdrawal methods which means it's a lot more secure.
So let's now have a look at the four access modifiers and we'll discuss their
effects and we'll produce some code to put these into practice.
So access control is granted by the top level or at the member level.
So at the top level.
What you can do is you can make your classes and
interfaces public or packaged private.
You can't define a private class at the top level as you can see if we try.
So let's try and do that.
So we try and create a new class and we'll call it private class.
So I come along and try him.
First, you add a constructor, that'll work.
But if I change this public to private, we got an error.
Modify private is not allowed here.
And that's telling us we can't have a private class at this level,
at sort of the top level of this file.
And let me just show down to this slide now,
we'll just talk about this a little bit more.
Just to confirm what can happen at the top level.
So basically, at a top level, only classes, interfaces and
enums can exist at the top level.
Everything else must be included within one of these.
So public means that the object is visible to all classes everywhere, whether they
are in the same package or have imported the package containing the public class.
Package-private, what that means is the object is only available
Within its own package and is visible to every class within the same package.
So package-private is specified by not specifying, if that makes sense.
In other words, instead of default, if you do not specify public
it's not actually a package-private key word as such.
You just remove public and leave it as a class and
then you get package-private for doing that.
This is an example of a top level public class as you can see on the screen there.
It's a standard public class definition there, and it's a public constructor.
Top level public interface, very similar as you can see there.
But again the public keyword The word interface, and
then obviously the name of the interface in this case.
Now our top level package-private class,
I mentioned that you remove the public, identify you can see on line three,
there's no public there it just says class.
Doesn't say define a package-private class.
And likewise for interface Package Private Interface,
we're moving the word Public again.
Now member level, this is once we're actually in the class itself.
Public, so you're seeing public at that level,
the member level Has the same meaning as the top level.
So in other words the public class member or field and public method
can be accessed from any other class anywhere, even in a different package.
And we saw that when we were using the main method.
To update the balance manually instead of going through the withdrawal and
deposit methods.
The package private also has the same meaning, it does at the top level.
An object with no access modifier is visible to every class within the same
package but not to classes in external packages.
And lastly private and we saw that when we changed the fields in the example code.
The object is only visible within the class it's declared in.
It's not visible anywhere else including in subclasses of its class,
that's very important to know as well.
Lastly, protected the object is visible anywhere in its own package, sort of like
package-private but Also in subclasses, even if they were in another package.
So that's you'd wanna use protected instead of private.
Okay, so let's go back and look at doing some more coding now.
So we've been using our access modifiers throughout this course.
And I briefly discussed the use of private in earlier lectures, but
now you've got an almost complete definition what they all mean.
Now I said almost complete,
because there's one case that was not specifically mentioned.
Although it was covered in the lecture on interfaces.
That case is part of the solution to our mini-challenge.
So what we're gonna do is I'm just going to delete this private class,
cuz we're not going to need that.
Now I'm gonna create an interface.
Gonna go New, Class, select Class, choose Interface, and
I'm gonna call this Accessible.
And we'll close the run window down.
So what I'm going to do now is paste in some code.
Now note I'm actually deleting this first part of the interface as well.
So I'm gonna paste it all in.
Okay, so the challenge is, in the following interface declaration,
what's the visibility of One, the accessible interface.
Two, the int variable constant.
Three, method A.
And four, method B and method C.
And what you might want to do is think back to the lecture
on interfaces before answering this.
So, pause the video at this point,
and when you come back, we'll go through and give you the answer to them all.
OK, how's it going?
Hopefully, you've figured it out.
So, firstly, let's talk about uncertain, number 1,
the accessible interface, what's the visibility of that?
Well, it's set to package private, so, in other words,
it's accessible to all classes, in this case, in the com dot timber package.
Because that's what I've defined above.
The second one, the int,
variable some underscore constant, the visibility was set to public,
and what that means is all interface variables are public static final.
And again that was the hint I gave back in,
I'll check the lecture on interfaces method C, or, sorry, number 3,
step 3, method A, On line 19, what's the visibility of that?
Well, it's public; it's just a standard public.
And we talked about that.
And method B and
method C are public because all interface methods are automatically public, so
the lack of an axis modifier here does not imply package private.
So that was a little bit of a trick question there,
and that's why I suggested you went back and check on interfaces.
So again, with method b and method c,
they're still public because this is an interface.
I was a little bit sneaky.
Sorry about that.
But it's not possible to have anything except public methods in an interface.
Now this does make sense, if you think about it, because the whole point of
declaring interface is to provide methods that have to be implemented.
So if you hide those methods in any class implementing the interface it will
struggle to implement the hidden methods which sort of defeats the whole purpose.
Purpose of using interface.
You can make the methods effectively package private
by ensuring that the interface itself is package private as we've done here.
And although all three methods are public, if the interface itself is not visible
outside the current package, then those methods obviously won't be visible either.
So that's it, you've now got the complete picture.
The lack of an axis modifier means the default of package
except with interface methods and variables, which arise public.
So that's it, I hope you've got a lot out of this video and
I'll see you in the next one.