Minimize the accessibility of classes and members

The rule of thumb is simple: make each class or member as inaccessible as
possible. In other words, use the lowest possible access level consistent with the
proper functioning of the software that you are writing.
For top-level (non-nested) classes and interfaces, there are only two possible
access levels: package-private and public. If you declare a top-level class or interface
with the public modifier, it will be public; otherwise, it will be package-private.
If a top-level class or interface can be made package-private, it should be. By
making it package-private, you make it part of the implementation rather than the
exported API, and you can modify it, replace it, or eliminate it in a subsequent
release without fear of harming existing clients. If you make it public, you are
obligated to support it forever to maintain compatibility.
If a package-private top-level class (or interface) is used by only one class,
consider making the top-level class a private nested class of the sole class that uses
it (Item 22). This reduces its accessibility from all the classes in its package to the
one class that uses it. But it is far more important to reduce the accessibility of a
gratuitously public class than of a package-private top-level class: the public class
is part of the package’s API, while the package-private top-level class is already
part of its implementation.

For members (fields, methods, nested classes, and nested interfaces), there are
four possible access levels, listed here in order of increasing accessibility:
• private—The member is accessible only from the top-level class where it is
declared.
• package-private—The member is accessible from any class in the package
where it is declared. Technically known as default access, this is the access level
you get if no access modifier is specified.
• protected—The member is accessible from subclasses of the class where it is
declared (subject to a few restrictions [JLS, 6.6.2]) and from any class in the
package where it is declared.
• public—The member is accessible from anywhere.

After carefully designing your class’s public API, your reflex should be to
make all other members private. Only if another class in the same package really
needs to access a member should you remove the private modifier, making the
member package-private. If you find yourself doing this often, you should reexamine
the design of your system to see if another decomposition might yield
classes that are better decoupled from one another. That said, both private and
package-private members are part of a class’s implementation and do not normally
impact its exported API. These fields can, however, “leak” into the exported API
if the class implements Serializable (Item 74, Item 75).
For members of public classes, a huge increase in accessibility occurs when
the access level goes from package-private to protected. A protected member is
part of the class’s exported API and must be supported forever. Also, a protected
member of an exported class represents a public commitment to an implementation
detail (Item 17). The need for protected members should be relatively rare.