The key to 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. This concept is known as information hiding (information hiding) or encapsulation (encapsulation).
The only reason for information hiding is because it effectively relieves the coupling between the modules that make up the system, enabling these modules to be developed, tested, optimized, used, understood, and modified independently. Although information hiding does not bring better performance, it can effectively adjust performance: Once a system is completed and the modules are determined to affect system performance (the optimization guidelines see 55th), those modules are optimized without affecting the correctness of the other modules. Information hiding can also improve the reusability of modules. Information hiding also reduces the risk of building large systems, even if the entire system is not available, but these standalone modules may be usable.
Using modifiers correctly is critical for information hiding.
The access control mechanism determines the accessibility of classes, interfaces, and members. The accessibility of an entity is determined by the location of the entity declaration and by the access modifiers that appear in the entity declaration.
1. Make every class or member inaccessible to the outside world as much as possible .
There are 4 possible levels of access for members:
1. Private: Only internal access is available.
2, Package-level private (Package-private): Default access level, the package inside the class can be accessed.
3, Protected (Protected): Allow access to subclasses and classes that are in the package.
4. Publicly available (public): accessible anywhere.
You should modify the private modifier only if the other class really needs to access the members of the class.
If the serializable interface is implemented, these private domains may be "leaked" to the API.