Java class access

In Java, you can also use an access indicator to determine which classes within a library can be used by users of that library. If you want a class that can be invoked by a client programmer, you can place a public keyword somewhere before the beginning curly bracket of the class body. It controls whether the client programmer can create an object that belongs to this class.
To control access to a class, the indicator must appear before the keyword class. So we can use:
public class Widget {
In other words, if our library name is Mylib, then all client programmers can access widget--through the following statement:
Import Mylib. Widget;
Or
Import mylib.*;
However, we should also note some additional restrictions:
(1) Each compilation unit (file) can have only one public class. The concept of a common interface for each compilation unit is expressed by that public class. Depending on your needs, it can have any number of "friendly" classes that provide support. But if you use more than one public class in a compilation unit, the compiler prompts us for an error message.
(2) The name of the public class must exactly match the name of the file containing the compilation unit, even its case. So for widgets, the name of the file must be Widget.java, not Widget.java or Widget.java. Similarly, if there is a discrepancy, a compile-time error is reported.
(3) It is possible (but common) that there is a compilation unit that does not have any public classes at all. At this point, you can arbitrarily specify the filename as you wish.

What happens when you've got a class inside the mylib and you're ready to use it to accomplish tasks performed by widgets or other public classes within Mylib? We don't want to spend a lot of time working on documentation for our client programmers, and feel like we might be making big changes at some point in the future and deleting our classes and replacing them with a different class. To achieve this flexibility, there is a need to ensure that no client programmer can rely on specific implementation details that are hidden within the mylib. To do this, you simply remove the public keyword from the class, which makes the class "friendly" (the class can only be used within the package).
Note that you cannot set a class to private (that would make it inaccessible to anything other than a class), and it cannot be set to protected (note ④). Therefore, we now have only two choices for class access: "Friendly" or public. If you don't want anyone else to access that class, you can set all the builders private. Thus, within a static member of a class, everyone other than yourself cannot create an object belonging to that class (comment ⑤). As shown in the following example:

: Lunch.java
//demonstrates class access specifiers.
Make a class effectively private
//with private constructors:

class Soup {
  private Soup () {}
  //(1) Al Low creation via static method: public
  static Soup Makesoup () {return
    new Soup ();
  }
  (2) Create a static object and
  //return a reference upon request.
  (the "Singleton" pattern):
  private static Soup PS1 = new Soup ();
  public static Soup access () {return
    PS1
  }
  public void F () {}
}

class Sandwich {//Uses lunch
  void F () {new Lunch ();}
}

Only one public class allowed per file: Public
class Lunch {
  void Test () {
    //Can ' t do this! Private constructor:
    //! Soup priv1 = new Soup ();
    Soup priv2 = Soup.makesoup ();
    Sandwich f1 = new Sandwich ();
    Soup.access (). f ();
  }
} ///:~

④: In fact, the Java 1.1 inner class can be either "protected" or "private", but that's a special case. The 7th chapter will explain the problem in detail.

⑤: It can also be achieved by inheriting from that class.

So far, most of the methods we've created are either to return void or to return a basic data type. Therefore, for the following definition:

public static Soup access () {
return PSL;
}

It's starting to get a little confusing. The word before the method name (access) indicates exactly what the method returns. Until then, all we see is void, which means "nothing returns" (void in English is "nothingness"). But it can also return a handle to an object, which is what happens at this point. The method returns a handle that points to an object in the class soup.
The soup class shows us how to prevent the creation of a class directly by setting all the builders private. Keep in mind that if you create at least one builder, you will automatically create a default builder (no arguments). If you write the default builder yourself, it will not be created automatically. When you turn it into private, no one can create an object for that class. But how do others use this class? The above example reveals two choices for us. First, we can create a static method, create a new soup from it, and return a handle to it. This is especially useful if you want to do some extra work on soup before you go back, or if you want to know how many soup objects you are going to create, perhaps to limit the number of them.
The second option is to use "design" techniques, which are described in detail later in this book. The usual scenario is called an "only child" because it allows only one object to be created. The object of the class soup is created as a static private member of the soup, so there is one and only one. You cannot access it at all unless you have access () by public method.
As noted earlier, if an access indicator is not set for access to a class, it automatically defaults to "friendly." This means that the object of that class can be created by other classes within the package, but not outside the package. Keep in mind that for all files in the same directory, if you do not explicitly make package declarations, they default to part of the default package for that directory. However, if the property of a static member of that class is public, the client programmer can still access that static member-even if they cannot create an object belonging to that class.