Hide the implementation scheme

To facilitate the discussion later, let's first classify the practitioners in this field. Fundamentally, two people are involved in object-oriented programming: "Class Creator" (the person who created the new data type) and "Customer programmer" (a person who uses ready-made data types in their own applications; annotation ④). The main goal for a client programmer is to collect a programming "toolbox" full of classes to quickly develop applications that meet their requirements. For class creators, the goal is to build a class from scratch, open only what is necessary to the client programmer (the interface), and hide all other details. Why did you do that? After being hidden, the client programmer will not be able to touch and change the details, so the creators don't have to worry about their work being illegally modified to make sure they don't affect others.

④: Thanks to my friend Scott Meyers, he helped me with that name.

The interface (Interface) sets out what requests can be made to a particular object. However, some code must exist somewhere to satisfy these requests. The code and the hidden data are called "hidden implementations." The whole problem is not complicated by standing in the direction of programming (procedural programming). A type contains functions that are associated with each possible request. Once a specific request is made to the object, that function is called. We typically summarize this process to "send a message" to an object (a request is made). The responsibility of an object is to decide how to respond to this message (execute the appropriate code).
For any relationship, it is important to have all the members involved adhere to the same rules. Creating a library is equivalent to building a relationship with a client programmer. The other is a programmer, but their goal is to assemble a specific application (program) or build a larger library with your library.
If anyone can use all the members of a class, the client programmer can do anything with that class, and there is no way to force them to obey any constraints. Even if the client programmer is very reluctant to manipulate some of the members contained within the class directly, there is no way to prevent it if there is no access control-everything will be exposed.

There are two reasons for us to control access to members. The first reason is to prevent programmers from touching things they shouldn't touch-usually the design idea of an internal data type. To solve a specific problem, the user simply has to operate the interface without having to understand the information. What we offer to our users is actually a service, because it's easy to see what's important to them and what's negligible.
The second reason for access control is to allow the library designer to modify the internal structure without worrying about what impact it will have on the client programmer. For example, we may have initially designed a simple class that simplifies development. Later, you decide to rewrite it to make it run faster. If the interface and implementation methods have been isolated, and protected, can be assured to do this, only to require users to relink.
Java uses three explicit (explicit) keywords and an implicit (implied) keyword to set class boundaries: public,private,protected and suggestive friendly. If you do not explicitly specify another keyword, the latter is the default. The use and meaning of these keywords are fairly intuitive, and they determine who can use the following definitions. "Public" means that any subsequent definition can be used by any person. On the other hand, private means that no one else can access subsequent definition information except yourself, the creator of the type, and the intrinsic function member of that type. Private has erected a wall between you and the client programmer. If someone tries to access a private member, you get a compile-time error. "Friendly" (friendly) involves the concept of "wrapper" or "encapsulation" (Package), the method that Java uses to build libraries. If something is "friendly", it means it can only be used within the scope of the package (so this access level is sometimes called "package access"). "Protected" (protected) is similar to private, except that an inherited class can access a protected member, but cannot access a private member. The question of succession will soon be addressed.