Java Hide Implementation Process

"For object-oriented design, one basic consideration is how to separate things that change from what remains unchanged." ”

This is particularly important for the library. The user of that library (the client programmer) must be able to rely on the part of their own use and know that once the new version of the library comes out, it doesn't need to rewrite the code. Instead, the creator of the library must be free to modify and improve, while ensuring that the client programmer's code is not affected by those changes.

In order to achieve this goal, a certain agreement or rule must be observed. For example, when a library programmer modifies a class in a library, it must ensure that the existing methods are not deleted because doing so can cause breakpoints in the client programmer code. However, the opposite is painful. For a data member, how can the creator of the library know which data members have been accessed by the client programmer? If the method is the only part of a class and is not necessarily used directly by the client programmer, then the painful situation is also true. What if the creator of the library wants to delete an old implementation and place the new code? Any changes made to those members could disrupt the client programmer's code. So the founder of the library is in an awkward position and seems to be unable to move at all.

To solve this problem, Java introduced the "Access indicator" concept, allowing the library creator to declare what is available to client programmers and which are not available. This level of access control is between "maximum access" and "minimal access", including public, "friendly" (no keywords), protected, and private. According to the description of the previous paragraph, you may have concluded that as a library designer, you should keep everything as private as possible and show only the methods that you want your client programmers to use. This idea is entirely correct, although it is somewhat contrary to the intuition of those who program in other languages (especially C), who are accustomed to accessing everything without any restrictions. By the end of this chapter, you should be able to appreciate the value of Java access control.

However, the concept of component libraries and the components that control who can access that library is not yet complete. There is still the question of how to bind a component to a single unified library unit. This is done through the Java Package (packaging) keyword, and the access indicator is affected by whether the class is in the same package or in a different package. So at the beginning of this chapter, you first need to learn how the library components are placed in the package. This will make it possible to understand the full meaning of the access indicator.