Java Scope, Part 2 — Methods, Fields, and this
Getting comfortable with object scope in Java
This is part two in my series on Java scope, written for beginners. The last post covered local variables and what happens when you wrap things in braces. This one takes it a step further and looks at how scope works when you start working with objects. If you want to start from the beginning, here’s part one:
One of the things that gave me the most trouble early on was how and when to use this. I’d write a constructor where the field and parameter had the same name, assume it was working, and then wonder why the field stayed null. I knew this had something to do with referring to the current object, but I didn’t really get how it worked in practice. It took a while, and more than a few broken constructors, before it finally clicked.
We'll go through the difference between fields and parameters, how method scope actually works, and why things behave the way they do once you start using constructors, instance variables, and static fields. It’s not heavy on theory, just the kind of practical stuff that helped me stop breaking things by accident.
Fields vs Parameters — and Why this Matters
This one was a big headache for me. I’d write a constructor like this:
At first it looked perfectly fine to me. I figured it was just setting the name. But it wasn’t. The field stayed null, and I couldn’t figure out why. For a while, I thought maybe Java was just being picky.
What’s really happening is that inside the constructor, the parameter name takes priority. So when you write name = name;, you’re just assigning the parameter to itself. The field name never gets touched.
The fix is adding this:
Using this.name tells Java you're talking about the field that belongs to the current object. The name on the right-hand side is still the parameter. After I understood that this was the way to reach the field from inside the constructor, everything started clicking.
I’ve made this exact mistake more times than I’d like to admit, and I still double-check my assignments in constructors just to be safe. If something looks like it should work but doesn't, and the names are the same, this is the first thing I look at.
The Scope of a Method
Every method in Java has its own space. Any variables declared inside it stay in that space. They’re created when the method starts, and they disappear as soon as it finishes.
The variable value is created inside methodA, and that’s the only place it exists. Even though both methods belong to the same class, methodB has no way to access it. Local variables show up when the method runs and disappear right after. If you need to pass information between methods or hold on to it for later, that’s what fields are for. Fields stay with the object as long as it exists. Local variables don’t. They live for the length of the method and then they’re gone.
Static vs Instance Fields
Static fields belong to the class itself. Instance fields belong to each object you create. That difference sounds small at first, but it can lead to bugs if you’re not watching for it.
Every time you make a new Counter object, it gets its own copy of localCount. But globalCount is shared across all of them. If one object changes it, every other object sees the updated value.
Static fields make sense in utility classes or when you really do need one shared value. Just keep in mind they carry over from one object to the next instead of starting fresh. I’ve run into bugs where a value kept going up and I couldn’t figure out why, until I realized a static variable was the reason. The same reminder applies to static methods, they belong to the class, so there’s no this to work with. They can only touch instance state if you hand them an object reference explicitly.
Field Scope and Visibility
Field visibility comes down to the access modifier you use, like private, protected, or public.
This doesn’t change how long the fields stick around, only who’s allowed to use them. If a field is marked private, only the class it belongs to can access it. If it’s public, anything with a reference to the object can reach in and use it.
I usually keep fields private unless there’s a specific reason not to. It keeps things a little more predictable and makes the rest of the code easier to work with later on.
Method Parameters Don’t Stay Forever
Method parameters only live inside the method where they’re declared. Once that method finishes running, the parameters disappear.
If you want to keep using a parameter after the method ends, you’ll need to assign it to a field or return it. Back when I was still getting used to how scope works, I remember thinking that passing a value into a method somehow made it available everywhere. But that’s not how Java works. It treats parameters just like any other local variable. They only exist inside the method and disappear when it finishes.
Conclusion
When you start working with objects, scope becomes a little more layered, but the rules stay clear once you’ve seen them in action. The parts that tend to trip people up usually come down to naming and forgetting what belongs to the method versus what belongs to the class. Walking through examples like this helps make those lines easier to spot, at least it was for me.
In the next one, I’ll cover how scope works in loops, lambdas, and streams. There are a few extra restrictions in those cases, but they all build on the same ideas we've already gone over.
If you’re following along or just like posts that break this kind of thing down, feel free to subscribe.