Inner class and tracing style

So far, the inner classes still look nothing special. After all, it seems a bit blowing out to use it to hide. Java already has a very good hiding mechanism--only allows the class to be "friendly" (visible only within a package), rather than creating it as an internal class.
However, when we are ready to go back to a basic class (especially to an interface), the inner class begins to play its key role (generating an interface handle from the object used for implementation has the same effect as tracing back to a base class). This is because the inner class can then be fully entered into an invisible or unavailable state-this will be true for anyone. So we can easily hide the implementation details. The full payoff we get is a handle to the underlying class or interface, and it may even be impossible to know the exact type. As follows:
 

//: Parcel3.java//Returning a handle to a inner class package c07.parcel3;

Abstract class Contents {abstract public int value ();}

Interface Destination {String readlabel ();}
    public class Parcel3 {private class Pcontents extends Contents {private int i = 11;
  public int value () {return i;}
    } protected class Pdestination implements destination {private String label;
    Private Pdestination (String whereto) {label = Whereto;
  Public String Readlabel () {return label;}
  Public destination Dest (String s) {return new pdestination (s); 
  Public Contents cont () {return new pcontents ();
    Class Test {public static void main (string[] args) {Parcel3 p = new Parcel3 ();
    Contents C = P.cont ();
    Destination D = p.dest ("Tanzania"); Illegal--can ' t access private class://!
  Parcel3.pcontents C = p.new pcontents (); }
} ///:~

Now, contents and destination represent interfaces that can be used by client programmers (remember that interfaces turn all their members into public properties). For convenience, they are placed in a single file, but the original contents and destination are public to each other in their own files.
In Parcel3, something new has been added: The Inner class pcontents is set to private, so nothing else can be accessed except PARCEL3. The pdestination is set to protected, so in addition to the classes in the PARCEL3,PARCEL3 package (because protected also gives the package access, that is, protected is "friendly"), and the successor to the PARCEL3, Nothing else can access pdestination. This means that client programmers will be limited in their understanding and access to these members. In fact, we can't even go back to a private inner class (or a protected inner class, unless we're a successor) because we can't access the name, as we see in Classtest. So, using private internal classes, class designers can completely prohibit other people from relying on type coding, and can completely hide the specific implementation details. In addition, from the client programmer's point of view, the scope of an interface is meaningless because they cannot access any additional methods that are not part of the common interface class. As a result, the Java compiler also has the opportunity to generate more efficient code.
Ordinary (non-internal) classes cannot be set to private or protected--only allow public or "friendly".
Note that contents does not have to be an abstract class. You can also use a generic class here, but the most typical starting point for this design is still an "interface."