Introduction

Access modifiers in Java are keywords that define the visibility and accessibility of classes, fields, methods, and constructors. They are a core part of Java’s encapsulation mechanism, enabling developers to control how components of a program interact with each other. By restricting access to internal implementation details, access modifiers promote modularity, security, maintainability, and robust API design. Java provides four access levels: private, default (package-private), protected, and public. Understanding when and how to apply each modifier is essential for writing well-structured, object-oriented Java code.

---

1. The Four Access Modifiers

Modifier	Class	Package	Subclass	World (Any Class)
private	✅	❌	❌	❌
default (no keyword)	✅	✅	❌	❌
protected	✅	✅	✅	❌
public	✅	✅	✅	✅

Note: "✅" means accessible; "❌" means not accessible.

---

2. Detailed Explanation of Each Modifier

A. private

• Most restrictive access level.
• Accessible only within the same class.
• Used to hide internal implementation and enforce encapsulation.

Example

public class BankAccount {
private double balance; // Only accessible inside BankAccount
public void deposit(double amount) {
if (amount > 0) {
balance += amount; // Allowed: same class
}
}
// Getter to safely expose balance
public double getBalance() {
return balance;
}
}

Best Practice: Make fields private and provide public/protected getters/setters as needed.

---

B. Default (Package-Private)

• Achieved by not specifying any access modifier.
• Accessible only within the same package.
• Ideal for internal helper classes or methods not meant for external use.

Example

// File: utilities/Logger.java (in package 'utilities')
class Logger { // Default access
void log(String message) {
System.out.println("[LOG] " + message);
}
}
// File: app/Main.java (in package 'app')
public class Main {
public static void main(String[] args) {
// Logger logger = new Logger(); // Compilation error: Logger not visible
}
}

Use Case: Package-level utility classes that should not be exposed outside the module.

---

C. protected

• Accessible within the same package and by subclasses in other packages.
• Used to allow inheritance-based access while restricting general public access.

Example

// Package: shapes
package shapes;
public class Shape {
protected String color; // Accessible to subclasses anywhere
protected void draw() {
System.out.println("Drawing a shape");
}
}
// Package: graphics
package graphics;
import shapes.Shape;
public class Circle extends Shape {
public void render() {
color = "Red"; // Allowed: subclass access
draw();        // Allowed
}
}

Note: A protected member is not accessible to non-subclasses in other packages.

---

D. public

• Least restrictive access level.
• Accessible from any class, regardless of package or inheritance.
• Used for APIs, entry points, and widely used components.

Example

public class Calculator {
public static double add(double a, double b) {
return a + b;
}
}
// Any class in any package can call:
// Calculator.add(2.5, 3.1);

Rule: A Java source file can contain only one public class, and the filename must match the class name.

---

3. Access Modifiers Applied To

A. Classes

• Can be public or default only.
• Cannot be private or protected (top-level classes).
• Nested classes can use all four modifiers.

public class PublicClass { }      // Accessible everywhere
class PackagePrivateClass { }     // Accessible only in the same package

B. Fields, Methods, and Constructors

• Can use all four access modifiers.
• Choose the most restrictive level that still allows required functionality.

C. Interfaces and Enums

• Implicitly public if declared public.
• Members of interfaces are implicitly public and static (for fields) or abstract (for methods).

---

4. Best Practices

• Minimize accessibility: Use the most restrictive modifier that works.
• Fields → private
• Helper methods → private or default
• API methods → public
• Extensible methods → protected
• Avoid public fields (breaks encapsulation). Use getter/setter methods instead.
• Use protected only when designing for inheritance.
• Prefer composition over inheritance—reduces need for protected.
• Document access intent in Javadoc, especially for protected members.

---

5. Common Mistakes

• Making fields public:

  public class BadExample {
public int id; // Allows direct, uncontrolled modification
}

Fix: Use private fields with controlled access via methods.

• Overusing public: Exposing internal methods increases coupling and reduces maintainability.
• Confusing protected with package access: Remember, protected includes subclasses in other packages.
• Declaring a class private (top-level): Not allowed—leads to compilation error.

---

6. Practical Example: Well-Encapsulated Class

package banking;
public class Account {
private String accountNumber;
private double balance;
private static final double MIN_BALANCE = 0.0;
// Public constructor
public Account(String accountNumber, double initialBalance) {
this.accountNumber = accountNumber;
this.balance = initialBalance;
}
// Public API
public void deposit(double amount) {
if (amount > 0) {
balance += amount;
}
}
public boolean withdraw(double amount) {
if (amount > 0 && balance - amount >= MIN_BALANCE) {
balance -= amount;
return true;
}
return false;
}
public double getBalance() {
return balance;
}
// Protected method for subclasses (e.g., SavingsAccount)
protected void applyInterest(double rate) {
balance += balance * rate;
}
}

• accountNumber and balance: private → safe from external tampering.
• deposit, withdraw, getBalance: public → part of the public API.
• applyInterest: protected → available to subclasses only.

---

Conclusion

Access modifiers are fundamental to Java’s object-oriented design, enabling precise control over how code components interact. By applying the principle of least privilege—granting only the access necessary—you create systems that are secure, maintainable, and resilient to change. private enforces encapsulation, default supports package cohesion, protected enables safe inheritance, and public defines clear APIs. Mastering access modifiers is not just about syntax; it’s about designing software that is modular, testable, and scalable. Always ask: “Who really needs to access this?”—and choose the appropriate modifier accordingly.