So in the previous video we talked about Scope for the first time.
So what we will do is we'll actually test that with a challenge at the end of
this video or possibly the next depending on how long the video goes for.
But we'll be talking about visibility.
In Java getting back to scope, things can be a little bit more complicated and
that's because objects themself also have visibility but before I actually go about
explaining that what we'll do is we'll do a bit of refactoring so
our private file variable names will have different variables themselves.
Have different names, which is going to make them easy for us to refer to.
So first the in scope check itself,
what we're going to do is we're going to refactor the private var, call it var one.
So I'm just going to click on that, right click, refactor 39,
I'm gonna call that DAR 1R1.
Noting all the places in the code where that's being updated.
Note down here Intuijay was smart enough to figure out, okay you're using the field
which is part of scope check, and it's updating that as well.
So I'm gonna press enter then, to accept that.
And I need to put a space there.
Actually, what I'll do is I'll undo that.
I'll try again.
I'll right-click, refactor, rename.
And I'll delete all this extra stuff out this time.
I wanna call this one var 1.
Var 1.
Press Enter.
And, it's actually telling us, do we want to actually rename the getter, as well.
And that can be a good idea because at the moment it's called getPrivateVar.
So I would say yes to that.
And down here, what we need to do is we need to actually click on Do ReFactor.
Basically, are we happy with the scope?
ANd this is the way that Intellgioso what's going to basically change.
In this case, it's quite Quite simple as you can see what can be changed.
But in cases where you've got a lot of code, you can actually come down here and
actually see all the places where the code's gonna be changed and
it can be really useful.
In this case, I'll click on do refactor.
And you can see we've changed all the variable names.
And also note the getter has now been changed as well.
I'm gonna change this, actually.
And then leave that as for now.
So let's scope check.
In the inner class what we want to do is we actually want
to rename the field to Val three.
So I'm going to come down here,
and rename that rather to Val three with re-factor, re-name.
Var three press Enter and
then again we're gonna do the refractor cuz there is more of a place.
I'm just gonna accept that, that's being updated and you're coming back here to
the scope check method times two, we're actually gonna rename that,
I could just type it but I'm just gonna refactor it again.
Refactor, rename, I could of pressed Shift+F6
there as you can see on the screen if I wanted to go directly to that.
And you just hit Shift+F6 also in Win Linux.
And delete that and we can change that and we'll call it varTwo.
Just so we're really clear now and incidentally when I did the first
refractor it also changed what was in double quotes.
So I could of actually got it just to change the variables,
just not make that other change but in this case I just accepted it all so
It actually has changed the actual name of the variable,
also in the double quotes as well, the actual string representation.
Lastly, going back to main, then here what we'll do just, again,
to be consistent we're gonna rename or refactor that.
I'm gonna call this file four.
Notice I will say that when we rename the getter it automatically changed that
in main method so again pretty cool how IntelliJ could do a lot of that work for
you, making things a lot easier.
Notice also what's happened here,
this is probably not what we wanted when I did the renaming of
in scope check for the third variable, I'll just go back and have a look.
var3. It actually renamed this as well and
that's because the match on the name.
I can actually rename that as well.
I'm going to change that back.
That should really be var1 now because this is where we're getting it from.
We're getting it from the scopeInstance and it should match that.
I'll just come back here.
I actually made a typo there.
I'll refactor that again.
[SOUND].
Let's call that bar three because then you can see that and
then you've got it working.
I am going back to the inner class.
What we're going to do there is we're going to actually show the bar three and
I actually bar three there.
Because that's actually what it is now.
So, I was showing the value of the inner class.
Let's also show value one as one.
So, value one, one is plus value one.
Plus in val three, and
coming back here I'll delete that method call which was an example.
And I'm going to actually print out file one is still available here.
You can see that we haven't got an error so
as far as is concerned, it's actually quite happy to put it in there.
So, now that I've done that,
the reason I was doing that is I want to show the scope of each variable in turn.
So, starting with varOne, a variable varOne,
the first one that we defined up here.
So, that scope is the entire class scope check,
you can see that's used in the constructor varOne.
But I've also actually put it in the inner class as well, you can see its in
the inner class constructor as well as the times two method.
So the class and all the interclasses have got access to varOne.
And that's because it's a field of scope check.
And because we renamed it, it's no longer shadowed by the inner class field,
cuz the inner class field has got a different name now, varThree.
That's why we can actually print it out without having to put a this prefix or
anything like that.
Let's fix that up there, but But also here in the time [INAUDIBLE] method.
We don't need to put this dot prefix because it;s
actually a different name now.
So what this confirms is that the object scope
is the block in which it's declared including any contained blocks.
So looking. Looking at varTwo,
and of course varTwo is here.
So looking at varTwo, that's defined in the timesTwo method for scopeCheck.
So that includes the for loop, and varTwo is also in scope with that as well as you
can see there, cuz it's defined above, and it'll work within the next set of blocks,
the enclosing blocks, if you will.
varThree, which is was field in our inner class, which is the inner class
to ScopeCheck That's in scope anywhere within the inner class, and
we've got it printed in the constructor as you can see.
Val3 there, and also multiplied in the times two method as well,
down here as well.
So that's [INAUDIBLE] those two places.
And finally, coming back to main, var4, the scope for
that's anywhere inside the main class and the main method,
because it's a local variable for the main method.
So it's worth noting here that at no time did any of our other
Private val variables shadow the one in main.
So that's a different class essentially.
So a variable can only shadow one with the same name if it's declared
in an enclosed block.
So that brings us to the next topic, which is visibility.
So in Java, an object's visibility is governed by the axis modifiers, and
we'll be discussing those in detail shortly.
But the thing to point out is that visibility is connected to scope, and
we need to look at that aspect of it first before covering the axis
modifiers themselves, and how they actually relate to axis control.
So getting back to our scope check If we look at the inner class
down at the bottom, starting at line 25, we've printed out the value 1 variable
despite the fact that it was the clearest private in the inner class.
And the inner class has access to all the inner class variables Or
fields of its containing class.
So not only is varOne in scope within the inner class it's also visible.
So the same is true the other way around.
So the containing class, you can also access all the methods and
fields of a contained class even if they're marked as private.
So we can actually check that.
But what we can do is create a method in scope check
to instantiate its inner class and print the varThree.
Variable.
So I'm gonna go in here making sure I'm actually within scope check,
I'm not in the inner class at all, and
I'm gonna do, create a method called public void useInner.
Within there I'm gonna type InnerClass, noting how IntelliJ can see that.
InnerClass InnerClass equals new InnerClass.
I can do system [INAUDIBLE] print var three
from outer class plus inner class.var three.
So now we've created the news inner, what we want to do is go back to the main
method and actually call that method that used inner method.
Up here, below the various print outs.
I want to actually put scope instance, dot, using R.
Just touch and make sure that works.
Going to run that.
Far three from error class three's, so you can see it's actually working fine there.
But, now if I actually go back to scope check, I can change this to a private.
Run it again, and the code still works.
So notice that the scope of our var 3 hasn't extended to the outer class.
So we actually had to qualify its name with the class instance
in order to print it out.
So, in a class.
As you can see there.
But the visibility does extend into the outer class, but
with that said the variable itself can't be accessed with any class external
to scope check and we can actually check that Ourselves by going back to main and
seeing if we can access it.
So I'm going to comb out some of these old lines for now.
Okay so after that then, if we actually set up here top scope, check.interclass.
In a class equals scope instance button new, in a class
and try and print out var three is not accessible here in
a class dot noticing how IntelliJ can't actually find the variable.
Now the reason we can't do that, we can't run it,
we actually get an error, is because var three's got private access and
therefore has no visibility outside its class or a containing class of its class.
So in other words, from ScopeCheck or ScopeCheck.InterClass.
But if we went back and actually changed this, changed that so it was a public.
Notice that the arrow disappeared from the, or the red disappeared from under
main.java and the error actually goes away because we've now given visibility for
that variable by to any other class.
So I'm just gonna undo that change.
Let's go back to a private again.
So this concept now is moving away from scope and into visibility and access.
But varOne and varThree's visibility within the scope check
is related to the scope of the variables, and
I think it's important to discuss that before we move on to access modifiers
Sort of properly, in particular, the fact that both var one and
var three are declared private, as you can see on the screen there.
Private on line eight, and
also on line 31, but both can be accessed from both the outer and inner.
Classes can actually be surprising when you're starting Java.
So finally when we look at inheritance, we often actually have a sub class override
a method from the superclass, in other words the class that it was extending.
So the mechanism for this is very similar into variable scope that we've discussed
so Java will look for a method in that case in the current class.
Can use that if it finds it, otherwise it's gonna look for
it in the immediate super class and so
on up the chain until it finds a class that actually has the method but
with that said it's not actually correct to say the overriding method shatters
the one in the superclass, override is actually the correct term here not shadow.
If though the method was static then it can be shadow dot overridden but for
now don't worry about that.
Until we get to the lecture on the static keyword.
Because I want to talk about that separately.
So time is ticking on.
I'm going to actually leave the challenge to the next video.
So the next video, we'll go through a challenge of the various things that
we've learnt in the last, in this video and the previous one.
So I'll see you in the next video.