Access Modifiers Explained

There are four levels. Private members are visible only inside the declaring class. Package-private members are visible to every class in the same package and nowhere else, which is the default when you write no modifier. Protected members are visible in the same package and to subclasses in other packages. Public members are visible everywhere.

public class Main {
    public static void main(String[] args) {
        Account a = new Account("Ada");
        System.out.println(a.owner());
        System.out.println(a.balance());
        a.deposit(50);
        System.out.println(a.balance());
    }
}

class Account {
    private final String owner;
    private double balance;
    Account(String owner) { this.owner = owner; }
    public String owner() { return owner; }
    public double balance() { return balance; }
    public void deposit(double amount) { balance += amount; }
}

The account class shows the practical default. The owner and balance fields are private, so nothing outside the class can read or write them directly. The three public methods form the class's public contract: you can ask who the account belongs to, ask the balance, and deposit money. The output shows the balance moving from zero to fifty through that contract only.

The ordering of the levels is a widening scale, from most restricted to least. Each step out makes the member available in more places, and with it more coupling, because every new place that can see a member is a place that can depend on it.

The one that catches people out is protected. It sounds like a compromise between package access and public access, but it does something package access does not: it reaches across package boundaries into subclasses. That is a coupling to a family of classes that you do not control and cannot see all of, which is why exposing protected mutable state is generally treated as a mistake.

Package-private access, which is what you get when you write no modifier, means the member is visible to every class in the same package and to nobody else. Protected access adds one thing on top of that: a subclass in a different package can also see the member, either through an inherited member or through a reference of the subclass type.

The practical difference shows up in two situations. A helper class in the same package can use a package-private member freely, which is how you share an implementation detail between closely related classes without making it part of the public API. Protected, by contrast, reaches out of the package and into a class hierarchy, so it creates a dependency between packages that the package structure did not ask for.

Another subtlety is that a protected member accessed through a reference of the subclass type is subject to different rules than one accessed from inside the subclass. In practice this is the part that generates confusing errors, and the reason most style guides advise keeping protected members read only, if you expose them at all.

For an interview, the crisp version is: package-private is a collaboration tool for code you own, and protected is an inheritance tool for code that extends you. Neither is public, and neither should be used casually for fields.

Because a protected member is an open contract to an unknown and unbounded set of classes. You cannot see your subclasses, you cannot know how they use the member, and you cannot change it later without breaking them. A protected field is also mutable, so every subclass can write to the state that you rely on for your own invariants, which means the parent class can no longer guarantee anything about itself.

The failure mode is quiet. A subclass sets a protected field to a value that the parent never intended, the parent trusts the field and misbehaves, and the bug surfaces far from the change that caused it. The parent class has lost control of its own state, which is the whole thing encapsulation exists to prevent.

The safer alternatives are worth listing. Make the member private and give the subclass a protected method that performs the operation correctly, so the rule stays in the parent. Or make the member final so the subclass can read it but cannot change it. Or drop inheritance for composition and pass the collaborator in, which removes the shared state entirely.

The design principle underneath all of these is that inheritance should extend behaviour, not expose state. A subclass that needs to influence the parent should do so through a well-defined operation, and the parent should keep the data and the rules together where it can enforce them.