Java-Preliminary Understanding-12th-Object oriented (access between packages and packages)

One.

There are a lot of different packages, how to access the classes between different packages? It is the default package when there is no package, the current directory is the default package, they are all in the same package to each other (access between different classes, call). Now what about the access between classes and classes in different packages?

In the auto-generated package in the previous section, the package name is determined according to the name written in the program. For example, it is written in the package mypack, so the auto-formed packet name is MyPackage, and at runtime it is explained where the package is formed (error, which is formed at compile time).

Now let's talk about the interaction between classes in the actual different packages.

(where is the source code located?) in different bags)

There are now two packages, MyPackage and Packagea packages, and MyPackage calls the classes in the Packagea package.

So who compiles first? Compile Demoa first, without Demoa, calling it will fail.

When talking about it, it seems that the Packagedemo class can be compiled directly, and the system will automatically look for the class to be accessed.

The story is true, why is it changing now? Actually did not change, previously was written in the same package, so it will be in the current package to find access to the class, no such class, the location of the. java file (once found, compile, and then continue to execute the program). This rule is still the same thing. Program in the execution, to find Demoa class files, if the Demoa class file in the current directory is not, then you need to find Demoa.java file, but this is a bit different before, this Demoa has belonged to.

So, the class you're going to use is actually packagea. Demoa.class file, if there is no such file, it will find the Packagea directory there is no Demoa.java file. It is based on your class name to find the source file name, (it seems that the principle of the search did not change, just to make a change based on location)

(I have a little bit of understanding, add the package statement of the program, using a slightly different method than before.) The class file that is now called must be the package name. Class name, which cannot be manipulated if the class file is only a class name. If there is no corresponding class file, the caller will go to the corresponding package file to find the class file of the corresponding class name. This class file requires the package name. The format of the class name? Do not need, in the source program needs, the location of the class files need to follow this specification)

Now you can demonstrate the entire process by demonstrating the operation.

In real operation, the Javac Demoa is used directly to get the Demoa.class file in the current directory, but it cannot be used when the Packagedemo class file is run because the name is incorrect. The Demoa class file here uses the name of the current package. Demoa.class, so that it does not work, the natural failure to run. (but compilation is still possible, forming the Demoa.class file in the current directory)

Now you want to modify it to a form that you can use. In fact, it has been said how to make it available in the form of two types: manual and Automatic. Now in the form of automatic operation, here to pay attention to a little, javac–d. Demoa.java, the name of the source code Demoa.java and the class name in the program has a weak relationship.

After automatic compilation (this is the result of manual operation), a Packa package is formed under the current directory, and a Demoa.class class file exists in the package.

Now Lenovo is the earliest example of the previous one, there are two source code in the current directory, there is a call and the problem is called. In fact, you can compile both, and finally run the calling class file. You can also just compile and run the call source program, it will automatically search for the called class file at run time, if it does not find the corresponding name of the source file, compile it, and then call its class file. Under the package mechanism, this principle is also applicable.

In the package mechanism, the first thing to note is that in the compilation run the source file name and the class file name are expanded, although the actual look of the name has not changed, but actually expanded.

After the package appears, the class file (that is, the bytecode file) can be detached from the Java source file. We just need to give the class file to someone else, so we don't have to use the source file for others. Now improve the difficulty of use, the compiled class file is completely proposed.

This enables the separation of source files and class files. Now then call the program to compile and run.

There were two errors in compiling and no Demoa was found.

Why did not write before, was in a bag, now divided into different bags. (When the source program writes, it is necessary to explicitly call the class's owning.) )

That is, to modify the source program

This is the correct class name, now continue to compile execution, and error

This time the display package does not exist,

Packa package not found in current directory

In fact, this is not difficult to understand, the compilation is carried out under the E:\JAVA0331\DAY12. Java source file compilation, Packagedemo.java source file at compile time, you need to call Packa.demoa file, but there is no packa package under the current file. This package is under the C drive, and you should set the Classpath to tell the virtual machine under what path (the previous set classpath knowledge has been forgotten. My understanding is this, in the current directory, Compile Packagedemo.java source file, use the Packa.demoa class, that is, in the current directory to find Packa package Demoa class files, if not, find the corresponding Demoa.java is also possible, unfortunately there is no such package. Here comes a question that must be the Demoa class file, not the. Java source file? Whichever file needs to be described in the program, under the corresponding package. Since the corresponding package is in the C drive, now we need to add the C drive, that is, the method of using set Classpath. I personally think that set CLASSPATH is adding a search path. What about the location of the class file and the set classpath? )。

Remember, when you configure a package, you directly configure the directory in which the package resides in Classpath, and do not configure the class file, because the package and class are a whole, (pointing to the owning of the package)

To continue compiling, or to make an error,

The report says that it is not public, it is talking about the issue of authority.

The package defines a class, if the class is to be accessed in the package, it must give it large enough permissions, the general permissions are not accessible. Package inside the class, if not add public, is in the package is encapsulated, is hidden, not that the addition of private is hidden.

Note that, with public, the source file name and the class name will be consistent.

After you have modified this, run the compilation again.

This means that the Demoa class has changed to public, but the show method is not public yet. Default permissions are not, it is also encapsulated.

The Demoa class needs to be recompiled because it has been modified.

There is no problem at this time, and the Packagedemo class file is also stored under the C-drive MyClass file.

Now is the real understanding of the use of permissions, package and package only reflect, a package can not reflect the use of permissions.

Two.

The inheritance problem between classes in different packages.

Create a new PACKB package, and the class inside,

The classes in the Packa package inherit the classes in the PACKB package, which is the inheritance between classes in different packages.

The notation above is wrong, demob does not exist, it has to be prefixed, it is not the same as before.

Since it is inherited, we can run the method () directly, because it inherits everything from Demob.

Compile, the source file written Demoa can also be compiled, the Packa package in the diagram is Javac–d c:\myclass Demoa.java generated. The following sentence javac–d C:\myclass Demoa.java is just a formality.

These pictures, the important point is two points, compile time in a fixed place to form a folder, run with a prefix name. Under the mechanism of the package, the premise is that the writing in the source code is very important.

Now consider the other problem, which is that the method of calling the parent class by the subclass is directly accessible,

At this point, a succession of B call method methods, and B call method methods, the results are the same, are Demob method run, now is asked to form the two things are the same, why also inherit?

It is wrong to say that the Packagedemo class does not inherit the Demob class, it can directly create the Demob class object and call its method directly. is to implement methods for accessing external classes by creating objects of external classes. The Demoa class is inherited to obtain the Demob method. The question now is what is inherited and what does not reflect the difference.

is not a subclass, methods can be taken over. The existence of this inheritance is, then, somewhat superfluous. Now for a permission modification, you are not allowed to access between different packages, but if it is an inheritance relationship, you agree to access. This is the special permission that is used for subclasses of different packages. The existence of public, anyone can use, there is no inheritance does not matter.

With protected permissions, only subclasses in different packages can use them. You cannot get the method of a different package if you create its object directly.

The result of running again is as follows, and not quite the same as before.

This protected is the fourth kind of permission that everybody learns, use not much, but must know. Only inherit, this function can go to use. In other words, only the system that you belong to can make you use it. This, in fact, is also called encapsulation. I'm not going to let a class that's not related to me, to access my feature, which is provided specifically for my subclass.

There are only two permissions that can be used between packages and packages, one is public, the other is protected, and protected can only be used by subclasses in different packages.

Java-Preliminary Understanding-12th-Object oriented (access between packages and packages)