Resolve the naming and accessing of package structures in Java programming

The naming of the package
Package names should be avoided from conflicting with other packages, so choosing a meaningful and unique name is an important aspect of package design. But programmers around the world are developing packages, and there is no way to know who is using what package name, so choosing a unique package name is a challenge. If we determine that a package is only used within our organization, we can ask an internal arbiter to ensure that there are no name conflicts between projects.

But this approach is impractical for the world as a whole. Package identifiers are simple names, and the only good way to ensure package names is to use Internet domain names. If the name of the company we work for is magic.lnc and the domain name of the company is magi c.com, the properties package statement should be:

Package com. Magic. Attr; Note that the domain name constituent elements here are in reverse order of a regular domain name.

If we adopt this usage, the package name we adopt will not conflict with anyone else's package name except for the possible conflict within our organization. If we do have a conflict within our organization (possibly a large enterprise), we can use a more specific domain name to further qualify. Many large companies have internal subdomains, such as east and Europe, which can be used to further qualify the package name:

　　package corn. magic.japan.attr;

Using this scheme can make the package name very long, but it is relatively safe. Programmers who use this technique do not choose the same package name, and programmers who do not use this technique do not choose the name we use.

Packet access
When declaring the accessibility of top-level classes and top-level interfaces in packages, you have two choices: package and public. Classes or interfaces that are public can be accessed by code outside the package, while types that are not public have package scope: they can be accessed by other code in the same package. But for code outside of the package, or even within the subpackage, it is hidden. When we declare types, we should declare only those types that other programmers need to use as public, and hide those types that belong to the implementation details of the package. This technique gives us a great deal of flexibility, because programmers are not dependent on the type of implementation details they cannot access, so we are free to change the implementation details when we want to.

Class members that are not declared public,protected, or private can be accessed directly by any code in the package, but are hidden from code outside the package. In other words, the default access modifier is "package", except for members of the interface whose default access modifier is" public".

There are no fields or methods declared private in the package that can be accessed by all the other code in the package, so classes in the same package are considered "friendly" or "trustworthy." This makes we can define the combination of reservation code (predefined code) and a placeholder (placeholder code) application framework, including a placeholder code is covered by a subclass of framework class. Predefined code can use package access modifiers so that other collaborating code within the package can access them directly, but is not accessible to users outside the package. However, the subpackage of the package in which the code resides is not trusted, and vice versa. For example, code decorated in package dit with the package access modifier cannot be accessed by code in its subpackage dit.dat, and vice versa.

Therefore, three different contracts are defined for each type:

Publi. Contract: defines the main functionality of the type. .protected contract: defines the functionality available to subclasses for specialized purposes. .package contract: defines the functionality available to other code within the package to enable collaboration between types within the package. All of these contracts require careful consideration and design.

Accessibility and and cover methods

Only methods that are accessible in a superclass can be overridden in a subclass. If a method in a superclass cannot be accessed, it cannot be overridden in a subclass even if the method in the subclass has the same name as the method. When a method is called at run time, the system considers its accessibility to determine which specific implementation of it to run.

The following deliberately constructed example explains it more clearly. Suppose we declare a abstract-base class in P1 package:

　　package P1;

　　{Ab Ab AbAb

　　public abstract class AbstractBase

　　private void pri() {print(" stractBase.pri() " ):} void pac () {print(" stractBase.pac() " );}

　　protected void pro() {print(" stractBase.pro()");}

　　public void pub() {print(" stractBase.pub() " );}

　　public final void show()

　　pri();

　　pac();

　　pro();

　　pub();

　　}

  }

In this class, we define four methods, each with a different access modifier, and the body of the method identifies itself only. The method show calls each of these four methods in turn on the current object, and when the method is applied to different subclass objects, it indicates which implementation of these methods was called.

Now we define the class Concretel, which extends the AbstractBase class but is in package P2:

　　package P2;

　　import P1.AbstractBase

　　public class Concretel extends AbstractBase{

　　public void pri(){print("Concretel.pri() " );}

　　public void pac(){print("Concretel.pac() " );}

　　public void pro(){print("Concretel.pro() " );}

　　public void pub(){print("Concretel.pub()");}

　　}

In this class, four methods in the superclass were redeclared and their implementations changed, which reported that they belonged to the con-cretel class. At the same time, their access rights are changed to public for other code to access. Execute the following code

　　new Concretel().show():

The following output will be produced:

　　AbstractBase.pri()

　　AbstractBase.pac()

　　Concretel.pro()

　　Concretel.pub ()

Because the private method pri cannot be accessed by subclasses (or other classes), the show method always calls an implementation of the pri method in the AbstractBase class. Pac methods with package access in the AbstractBase class cannot be accessed by Concretel, so the implementation of pac methods in the Concretel class cannot override the definition in the AbstractBase class, so the show method calls the abstractbase.pac method. Both the pro and pub methods are accessible in the Concretel class and can be overridden, so the implementation of both methods in the Concretel class is called in the show method.

Then we'll add our Concrete2 class to extend the class Concretel, and then we'll put it in the same package P1 as the AbstractBase class ':

　　package P1;

　　import P2.Concretel

　　public class Concrete2 extends Concretel{

　　public void pri(){print("Concrete2.pri() " );}

　　public void pac(){print("Concrete2.pac () " );}

　　public void pro(){print("Concrete2.pro() " );}

　　public void pub(){print("Concrete2.pub()");}

　　}

Because the methods in Concretel all have public access, they are all accessible in Concrete2, and each method in Concrete2 overrides its corresponding method. In addition, because Concrete2 and ab-stractbase are in the same package, the method abstractbase.pac is also accessible in Concrete2, and the method concrete2.pac can be overridden. Call the show method on the Concrete2 object and print the result as follows:

　　AbstractBase.pri()

　　Concrete2.pac()

　　Concrete2 .pro()

　　Concrete2.pub()

Finally, we define the class Concrete3 to extend the class Concrete2 and place it in the package P3:

　　package P3

　　import P1.Concrete2;

　　public class Concrete3 extends Concrete2{

　　public void pri(){print("Concrete3.pri() " );}

　　public void pac Q{print("Concrete3.pac() " );}

　　public void pro(){print("Concrete3.pro() " );}

　　public void pub(){print("Concrete3.pub() " );}

　　}

 in Concrete3 Call on object show Method, print the result as follows :

　　AbstractBase.pri()

　　Concrete3.pac ()

　　Concrete3.pro()

　　Concrete3.pub()

Here the method concrete3.pac appears to override the unreachable abstractbase.pac method, but in fact the method concrete3.pac overrides the method concrete2.pac, so the method concrete3.pac indirectly overrides the method abstractbase.pac. By redeclaring the pac method as public access in class Concrete2, you can make it accessible and overridden by any subclass. '