Effective Java

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 implementa-
tion detail (Item 19). The need for protected members should be relatively rare.
There is a key rule that restricts your ability to reduce the accessibility of meth-
ods. If a method overrides a superclass method, it cannot have a more restrictive
access level in the subclass than in the superclass [JLS, 8.4.8.3]. This is necessary
to ensure that an instance of the subclass is usable anywhere that an instance of the
superclass is usable (the 
Liskov substitution principle
, see Item 15). If you violate
this rule, the compiler will generate an error message when you try to compile the
subclass. A special case of this rule is that if a class implements an interface, all of
the class methods that are in the interface must be declared public in the class.
To facilitate testing your code, you may be tempted to make a class, interface,
or member more accessible than otherwise necessary. This is fine up to a point. It
is acceptable to make a private member of a public class package-private in order
to test it, but it is not acceptable to raise the accessibility any higher. In other
words, it is not acceptable to make a class, interface, or member a part of a pack-
age’s exported API to facilitate testing. Luckily, it isn’t necessary either because
tests can be made to run as part of the package being tested, thus gaining access to
its package-private elements.
Instance fields of public classes should rarely be public
(Item 16). If an
instance field is nonfinal or is a reference to a mutable object, then by making it
public, you give up the ability to limit the values that can be stored in the field.
This means you give up the ability to enforce invariants involving the field. Also,
you give up the ability to take any action when the field is modified, so