Minimize the accessibility of classes and members.

The most important factor in distinguishing between well-designed modules and poorly designed modules is whether the module hides its internal data and other implementation details for other external modules. A well-designed module hides all the implementation details and separates its APIs from its implementation clearly. Then, the modules communicate only through their APIs, and a module does not need to know the internal work of other modules. This concept, known as information hiding (information hiding) or encapsulation (encapsulation), is one of the basic principles of design patterns.

The Java programming language provides many mechanisms (facility) to assist in information hiding. The access control mechanism determines the accessibility of classes, interfaces, and members (accessibility). The accessibility of an entity is determined by the location of the entity declaration and by the access modifiers (private, protected, and public) that appear in the entity declaration. Using these modifiers correctly is critical to implementing information hiding.

The first rule is simple: make every class or member inaccessible to the outside world as much as possible. in other words, you should use the minimum level of access that is consistent with the corresponding functionality of the software you are writing.

For top-level (not nested) classes and interfaces, there are only two possible levels of access: package-level Private (package-private) and public. If you declare a top-level class or interface with the public modifier, he is publicly owned, otherwise he will be a package-level private. If a class or interface can be made into a packet-level private, he should be made into a packet-level private. By making a class or interface private, it is actually part of the implementation of the package, rather than part of the API exported by the package, which can be modified, replaced, or deleted in future hairstyles, without fear of affecting the existing client program. If you make it public, you have the responsibility to support it forever to maintain their compatibility.

If a package-level private top-level class (or interface) is used only in the interior of a class, consider making it a private nested class of the class that uses it. This narrows the scope of his accessibility from all classes in the package to the class that uses him. However, reducing the accessibility of unnecessary public classes is much more important than reducing the level of proprietary top-level classes: because the public class is part of the package's API, the top-level class of the package-level private is already part of the implementation of the package.

There are four possible levels of access for members (fields, methods, nested classes, and nested interfaces), listed below in ascending order of accessibility:

Private--This member can be accessed only within the top-level class that declares the member. Package-level private (package-private)--This member can be accessed by any class within the package that declares the member. Technically, it is called the default access level, and if no access modifiers are specified for the member, the access level is applied. protected (Protected)--a subclass of the class that declares the member can access this member (with some restrictions), and any class within the package that declares the member can access the member. Public--the member can be accessed anywhere. The instance domain must not be public. If the domain is not final, or a final reference to a Mutable object, the ability to limit the values stored in this domain is discarded once the domain is publicly owned; This means that you also give up the ability to force the domain to be immutable. At the same time, when the domain is modified, you also lose the ability to take any action against him. Soclasses that contain public mutable domains are not thread-safe. Myopia is final and references immutable objects, and when the domain becomes public, the flexibility to "switch to a new internal data representation" is discarded. The same suggestion applies to static domains, except for one exception. Assuming that the constants form part of the entire abstraction provided by the class, these constants can be exposed through the public static final domain. By convention, the names of such fields are made up of uppercase letters, and the words are separated by an underscore. It is important that these fields either contain values of the base type or contain references to immutable objects. If the final field contains a reference to a Mutable object, it has all the disadvantages of a non-final domain. Although the reference itself cannot be modified, the object that he refers to can be modified--that can lead to disastrous consequences. Note that an array of nonzero lengths is always variable, soclass has a shared static final array field, or it is almost always wrong to return the access method for such a domain. If a class has such a domain or access method, the client will be able to modify the contents of the array, which is a common source of vulnerability://potential security hole. public static final thing[] VALUES = {...}; Note that many Ides produce an access method that returns a reference to a private array field, which can cause this problem. There are two ways of correcting this problem. You can make a shared array private and add a publicly immutable list: private static final thing[] Private_values = {...}; public static final List<thing> VALUES = Collections.unmodifiablelist (Arrays.aslist (private_values)); Alternatively, you can make the array private and add a public method that returns a backup of the private array: private static final thing[] Private_values = {...}; public static final thing[] values () {return private_values.clone (); In summary, you should always reduce accessibility as much as possible. After you have carefully designed a minimal public API, you should prevent any scattered classes, interfaces, and members from becoming part of the API. In addition to the special case of the public static final domain, public classes should not contain public domain. and to ensure that the objects referenced by the public static final domain are immutable.