Object-Oriented Programming
Access Modifiers
Deconstruct Java's four visibility levels (public, protected, package-private, private) and encapsulation rules.
Interview: Tests accessibility scopes, subclass vs package visibility, overriding rules (cannot reduce visibility), and encapsulation safety.
Access Modifiers define the visibility and accessibility boundaries of classes, constructors, fields, and methods. Choosing appropriate access levels is fundamental to enforcing object-oriented encapsulation.
Core Idea
Access modifiers control visibility. They range from public (unrestricted) to private (confined to the defining class).
Why It Matters
Overriding methods cannot reduce the visibility of parent methods, enforcing LSP subclass contracts.
Interview Lens
Tests overriding limits, default vs protected packages boundary rules, and class access combinations.
The Four Visibility Levels
Java has four distinct access levels:
| Modifier | Class | Package | Subclass (Diff Pkg) | World (Diff Pkg) |
|---|---|---|---|---|
public |
Yes | Yes | Yes | Yes |
protected |
Yes | Yes | Yes (via inheritance) | No |
| default (no modifier) | Yes | Yes | No | No |
private |
Yes | No | No | No |
Method Overriding and Visibility Rules
When overriding inherited methods, Java enforces a strict subclass constraint:
An overriding method cannot assign a weaker access privilege. For example:
- If a parent method is declared
protected, the subclass overriding method must beprotectedorpublic. It cannot be default orprivate. - Reducing visibility violates type substitutability (Liskov Substitution Principle), as code expecting the parent's public API would fail on child instances.
Common Pitfalls
- Reducing visibility on override: Attempting to override a protected parent method with package-private visibility, causing compile errors.
- Exposing mutable state: Declaring fields as public, allowing external code to modify internal states directly.
- Confusing default and protected: Assuming default visibility allows subclass access outside the package.
Best Practices
- Declare all instance variables as
privateto maintain encapsulation control. - Follow the Principle of Least Privilege: declare members with the most restrictive visibility possible (e.g. private first, only widening scope as needed).
- Avoid using protected fields unless they are specifically designed for subclass extension. Prefer private fields with protected accessor methods.
Interview-Relevant Information
Q1: Why is an overriding subclass method not allowed to reduce the visibility of the parent method?
Answer: Doing so violates polymorphism contracts (Liskov Substitution Principle). Subclass instances must be substitutable for parent types. If a client expects a public method defined in the parent, reducing it to private in the subclass would break the client code.
Q2: What is the difference between protected and default (package-private) visibility?
Answer: Default members are visible only to classes in the same package. Protected members are visible to classes in the same package, and additionally to subclasses located in different packages (accessed via inheritance).
Quick Checklist
Can you specify visibility matrix parameters, prevent compilation bugs when overriding methods, choose correct scopes, and implement encapsulated class variables? If yes, you understand access modifiers.
Use Cases
Encapsulating user credential models inside secure private fields.
Exposing library extension interfaces using protected methods.
Common Mistakes
Narrowing access bounds in child override methods.
Declaring public fields unnecessarily, exposing variables to direct external modification.