What is the difference between public, protected, package-private and private in Java?

java

encapsulation

access-modifiers

oop

byNikita Barsukov·Sep 26, 2024

Java access modifiers control where a class or class member can be accessed:

public: No restrictions; accessible from any other class.
protected: Package access plus outside packages via inheritance.
package-private (default): Only within the same package.
private: Strictly within the declaring class only.

Short example:

public class AccessExample {
    public int wideOpen;          // Available to all, no exceptions!
    protected int extendedFamily; // Available to family members, and distant cousins too.
    int neighborsOnly;            // Shhh...it's a neighborhood secret.
    private int myEyesOnly;       // Double-O Seven(007) stuff.
}

Strategies for Encapsulation

Encapsulation is the heart of object-oriented programming. It means organized, maintainable and secure code. The access modifiers are the real tools in your toolbox to enforce encapsulation.

Private-first approach

By default, the members of a class should be private. Only when there's a strong justification, we should increase the access. This ensures strong encapsulation by protecting the internals of a class from unwanted external interaction. So, keep it private unless the gossip is too good to keep!

Public sparingly

Let's call public the VIP lounge access. Add class members here and they are open to the world. So this lounge should only have members that you are willing to expose and commit to. Because once it's public, everybody uses it and you can't just change it without making few enemies.

Protected for heritage

With protected access, you're making a two-fold promise: not only allowing access to the same package, but also opening it for inheritance. So it becomes a legacy handed down to subclasses. A protected member is your family jewel, ready to be passed down to your OOP heirs, but need to be safe from the curious outsiders!

Remember to use the @Override annotation when you intend to override a method to avoid accidental overrides.

Understanding Access Levels

Package-private — Hidden in Plain Sight!

When there's no modifier, it's package-private. It's like a secret handshake in a secret society. It is open to classes within the package, a good balance between accessibility and encapsulation. Your secret handshake is the code that works within the shadows of your package.

Protected — Inheritance and Access Balance

Protected is like the backstage pass in a concert. It’s more open than package-private, giving potential super fans (subclasses) a chance to meet the band (base class). This can lead to fanatics who overly rely on the band's internals causing potential code fragility. So remember to design protected members being conscious of eager fans!

Public — Handle with Care!

Public is like the stage - out in the open and what everyone sees. Everyone can access your precious variable or method. Therefore, being public means you put on a great show and make very little changes. The more public you are, the more stable—and inflexible—you become.

Private — Internal Affairs!

Private members are like personal diaries, a treasure chest of secrets. Totally hidden from peering eyes. The owner of the diary has complete freedom to change the content as much as they want.

Deep-Dive into Design

Blueprint for extending classes

Protected abstract methods act as a blueprint for the extension. These methods embrace flexibility and are ready to be tailored by the subclass tailors. By doing this, you reduce dependency while increasing extensibility.

Module stability and flexibility

Access modifiers dictate the flexibility of your module design. The more public your interface, it is more stable and less flexible it needs to be, as opposed to private which would lead to a more flexible and versatile design.

Gradual accessibility

Always start with less access (private) and gradually increase visibility as per requirements. The choice of access modifiers is guided by how open-ended, stable, or flexible our software system needs to be.