From C + + to Java: Understanding the key to object-oriented

Java runs on a virtual machine

The Java source code is not compiled into normal machine code. Instead, it is translated into code that the virtual machine can execute. A Java interpreter eventually executes the code. This does not involve the process of connecting, explaining the dynamic loading of classes when needed;

Java is a fully object-oriented

Java is a fully object-oriented language. This means that the actions you do with any Java object are implemented in one way. The 1th is that there is no such thing as an isolated object without the main function. Instead, you have to start looking at a program, a class object, with an object's perspective. But what object is this object? Most Java programs simply do what you need by inheriting Java base class object, but you can save time by creating a program base class for applications with similar features.

Strict object-oriented rules mean that the original C/s + + code should not be used directly without modification; So is the system call. In C + +, you can use the original C procedure call, including system calls, by declaring extern "C" outside the normal namespace of C + +.

In Java, there is only a similar method of security backtracking, but it is not a very simple method. You must define a local method, which is designed to provide an interface for the C language and then provide the connected media. The Java environment provides the tools to do this, but the entire process and the extern ratios provided in C + + are trivial, and the process of completing the use of C + + classes is more complex, because it introduces the excuse for C and C and C + + member functions.

Fortunately, many of the commonly used system utility functions are already available in methods in the System class, but these obviously do not contain the classes and processes that you have created over many years. So you should delve into it when you need it.

There is no separate header file in Java

In Java, everything about a class is placed in a separate file. The location of a method can only occur in one place, and the implementation of a method must be performed concurrently in its definition. The advantage of this is that it is not easy to implement a program because of a file's asynchronous error, or to obtain a declaration that is not implemented. The declaration of a class can be exploited by the Java interpreter or even from a compiled unit, so there is no need for a header file, as long as there are compiled files.

The disadvantage of doing so is related to the process of our programming. Many C + + programmers prefer to use header files instead of documents. To see the interface parameters of a member function, you only need to look at the declaration in the file. You can learn how to use this class often by seeing the file. In Java, there is no such summary. Because the code that implements the class method must appear at the time of the method definition, and for the code of a single function, it often occupies a whole page or more. In this way, it is difficult to see the Java code to understand how the class is used. You have to prepare enough documents for the classes that you need. It goes without saying that documents are extremely scarce when dealing with non-commercial libraries.

Two tools are available in the first-world Java environment to compensate for these, javap to print class identities, and Javadoc provides HTML documentation for embedded programs.

Using package to decompose Java namespaces

One problem that is often encountered in large C + + engineering is namespaces-how do you guarantee that some programmers of the project will not create classes that have the same name as other programmers? Worse, the vendor may provide a library of classes that contain the same name as your class. There are many ways to solve this problem, but it is likely that the project has been started before the problem is discovered, and it will take a lot of pain to correct the mistake.

Java solves this problem through the concept of "Package", Package effectively divides namespaces by collection classes. Two classes with the same name in different packages are still different. The key question becomes whether the class is placed in the appropriate package.

Remember, Java does not solve the naming conflict problem. Extends a base class and causes a conflict of derived classes. For example, if your favorite vendor provides classes and then you make them as base classes and derives a class with the Foo method, it can occur when the vendor provides a new version of the class, and if the supply business also provides a method for Foo in the new class.

Exceptions are an important feature of Java

In C + +, exception and exception handling are very esoteric things; many C + + programmers have never dealt with them or even know what they are. Exceptions are unexpected errors that occur during normal processes, so they are not returned from the method or passed as arguments, but they cannot be ignored! An example here is the method of calculating the square root of a book.

The normal interface form is to pass a positive number as a parameter to the method, and then the method returns a positive real number as the result, and the method can examine these and throw an exception when the exception is generated. In most systems, programmers do not have to do this so that an exception that is not considered can cause the program to exit abnormally.

In Java, exceptions have become a very mature part of the language. The description of the method contains information about the exception, and the program processor also enforces that if you use a method that produces an exception, you must check to see if the exception occurs. Almost all Java programmers encounter an exception because classes in many very useful libraries throw exceptions. Handling exceptions is not difficult, but at some point you need to be aware of them. The document of a method indicates the type of exception that the method throws. If you forget, it doesn't matter, the compiler will remind you.

String is no longer a character array

Java contains an object of a string, and is a constant. Strings are not like character arrays, although you can simply construct a string from a character array. You should use strings instead of character arrays as much as possible, because they are not overwritten by misoperation.

Java restricts constant objects and methods

In C + +, you can formally declare that a function argument or function return value is a const type, which can effectively prevent improper modification of parameters or return values. In addition, you can declare a member function as const, indicating that it cannot modify any object that he is manipulating.

Java supports constant operators, read-only variables, which are implemented through the final keyword. However, Java does not support forcing a writable variable to become read-only during function passing and return. Or define a constant method that does not manipulate the modified object.

In Java, the effect of this omission is very small compared to that in C + +, largely because of the difference between string variables and character arrays, but this also poses a risk of causing errors. In particular, there is no way to test whether a method can alter an object.