Public vs Private vs Protected
Public, private and protected access modifiers compared — scope, inheritance rules and when to use each — with a Java example.
Expected Interview Answer
"public" members are accessible from any class anywhere, "private" members are accessible only within the declaring class itself, and “protected” members are accessible within the same package plus any subclass, even in a different package.
The three sit on a widening spectrum of visibility, with package-private (Java's no-modifier default) falling between private and protected. "private" is the tightest choice and the default for fields under encapsulation, since it forces all access through the class's own controlled methods. "protected" exists specifically to support inheritance — a subclass in another package can directly use a protected member it inherited, which plain package-private access would not allow. "public" defines the deliberate external contract of a class and should be reserved for what callers genuinely need; every public member becomes part of the API that other code can depend on and that becomes harder to change later without breaking callers.
- private locks implementation details behind controlled access
- protected supports inheritance while still restricting outside access
- public defines an intentional, stable contract for external callers
- Together they let a class expose exactly as much as necessary, no more
AI Mentor Explanation
A player's personal fitness data is private — visible only to that player. Their batting technique notes are protected — shared with coaches and any player who moves into the same specialized role, even at a different club, because the technique knowledge transfers. The final match scorecard is public — anyone, anywhere, can view it. The tighter the data, the more control the owner keeps over who touches it, exactly like private, protected, and public members in a class.
Step-by-Step Explanation
Step 1
Start with private
Default every field to private so all access goes through the class's own methods.
Step 2
Promote to protected only for inheritance
Widen a member to protected only when a subclass genuinely needs direct access.
Step 3
Promote to public deliberately
Expose a member as public only when external callers genuinely need to use it.
Step 4
Treat public as a contract
Remember every public member becomes an API other code can depend on — change it carefully.
What Interviewer Expects
- Correct definitions and correct ordering of scope: private < package-private < protected < public
- Understanding that protected exists specifically to support cross-package inheritance
- Awareness that overriding cannot narrow visibility below the parent method's level
- A concrete example distinguishing all three in one class hierarchy
Common Mistakes
- Saying protected is equivalent to private (protected is far more open — package plus subclasses)
- Assuming protected members are accessible from any class, not just subclasses and the package
- Treating public as the safe default instead of the most restrictive option
- Forgetting protected still allows package-level access, not just subclass access
Best Answer (HR Friendly)
“Private means only the class itself can use that field or method — it's completely internal. Protected widens that a bit so subclasses can use it too, even in a different package, which is useful when a child class needs direct access to inherited behavior. Public means anyone, anywhere, can use it — it's the class's real external interface. Generally you start as private and only widen access when there's a genuine need.”
Code Example
class Shape {
private String id; // only Shape itself can access
protected double area; // Shape, subclasses, same package
public Shape(String id) { // public constructor, external contract
this.id = id;
}
public String getId() { // public accessor to private data
return id;
}
}
class Circle extends Shape {
Circle(String id, double radius) {
super(id);
this.area = Math.PI * radius * radius; // protected: direct access OK
}
}Follow-up Questions
- Where does package-private fit between private and protected?
- Can a protected member be accessed by an unrelated class in the same package?
- Why is private the recommended default for fields?
- How do access levels affect what you can safely change in a public API later?
MCQ Practice
1. Which access level allows visibility to subclasses even in a different package?
protected is specifically designed to allow subclasses outside the package to access the member.
2. What is the correct order from most restrictive to least restrictive?
Visibility widens from private, to package-private, to protected, to public.
3. Why is “private fields, public methods” a recommended pattern?
It keeps internal state protected while still letting external code interact through a deliberate, controlled interface.
Flash Cards
private in one line? — Accessible only within the declaring class.
protected in one line? — Accessible within the same package and by subclasses elsewhere.
public in one line? — Accessible from any class, anywhere.
Recommended default? — Start private, widen to protected or public only when genuinely needed.