Shulou(Shulou.com)06/02 Report--

Write Java program what are the 30 basic rules, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

(1) the first letter of the class name should be capitalized. The initials of fields, methods, and objects (handles) should be lowercase. For all identifiers, all words contained in it should be close together and capitalize the first letter of the middle word. For example:

ThisIsAClassName

ThisIsMethodOrFieldName

If a constant initialization character appears in the definition, all letters in the static final base type identifier are capitalized. This indicates that they belong to the constants at compile time.

Java packages (Package) are a special case: they are all lowercase letters, even the middle words. Domain name extensions, such as com,org,net or edu, should all be lowercase (this is also one of the differences between Java 1.1 and Java 1.2).

(2) when creating a class for general use, take "classic form" and include definitions of the following elements:

Equals ()

HashCode ()

ToString ()

Clone () (implement Cloneable)

Implement Serializable

(3) for each class you create, consider placing a main () that contains the code used to test that class. In order to use the classes in a project, there is no need to delete the test code. If you make any kind of changes, you can easily return to the test. This code can also be used as an example of how to use a class.

(4) the method should be designed as a brief, functional unit, which can be used to describe and implement a discontinuous class interface. Ideally, the method should be concise and to the point. If the length is large, consider dividing it into shorter methods in some way. This also facilitates reuse of in-class code (sometimes methods have to be very large, but they should still only do the same thing). (5) when designing a class, put yourself in the shoes of the customer programmer (the use of the class should be very clear). Then put yourself in the shoes of the person who manages the code (anticipate what forms of changes are possible and think about ways to make them easier).

(6) make the class as short as possible and solve only one specific problem. Here are some suggestions for class design:

■ A complex switch statement: consider using the "polymorphic" mechanism

A large number of ■ methods involve operations that vary greatly in type: consider using several classes to implement each

Many ■ member variables differ greatly in characteristics: consider using several classes.

(7) make everything "private" as much as possible-private. You can "publicize" a part of the library (a method, class, field, etc.), and you can never take it out. If you force it out, it may destroy other people's existing code, forcing them to rewrite and design it. If you only publish what you must publish, you can rest assured and boldly change anything else. Privacy is a particularly important factor in a multithreaded environment-only the private field can be protected in the event of asynchronous use.

(8) beware of "giant object syndrome". For some novices who are accustomed to sequential programming thinking and are new to the field of OOP, they often like to write a sequentially executed program first and then embed it in one or two huge objects. According to programming principles, objects should express the concept of the application, not the application itself.

(9) if you have to do some indecent programming, you should at least put that code inside a class.

(10) whenever you find that classes and classes are very closely integrated, you need to consider whether to use inner classes, so as to improve coding and maintenance (see "improving code with inner classes" in Chapter 14, section 14.1.2).

(11) annotate as carefully as possible, and use javadoc comment document syntax to generate your own program documentation.

(12) avoid using "magic numbers", which are difficult to match well with the code. If you need to modify it in the future, it will undoubtedly become a nightmare, because you don't know whether "100" means "array size" or "something completely different". Therefore, we should create a constant, use a persuasive descriptive name for it, and use constant identifiers throughout the program. This makes the program easier to understand and easier to maintain.

(13) when it comes to builders and exceptions, you usually want to re-discard any exceptions caught in the builder if it causes the creation of that object to fail. In this way, the caller will not assume that the object has been created correctly and continue blindly.

(14) when the customer programmer has finished using the object, if your class requires any cleanup work, consider putting the cleanup code in a well-defined method, using a name like cleanup () to clearly indicate your purpose. In addition, you can place a boolean (Boolean) tag within the class to indicate whether the object has been cleared. In the finalize () method of the class, make sure that the object has been cleared and that a class inherited from RuntimeException (if not yet) has been discarded, thus pointing out a programming error. Before taking a scenario like this, make sure that finalize () can work on its own system (you may need to call System.runFinalizersonExit (true) to ensure this behavior).

(15) in a specific scope, if an object must be cleared (not handled by the garbage collection mechanism), use the following methods: initialize the object; if successful, immediately enter a try block containing finally clauses and start the cleanup work.

(16) if you need to override (cancel) finalize () during initialization, remember to call super.finalize () (this is not necessary if Object belongs to our direct superclass). During the override of finalize (), the call to super.finalize () should be an action, not an action, to ensure that the underlying class components are still valid when they are needed.

(17) when you create a fixed-size collection of objects, transfer them to an array (especially if you are going to return this collection from a method). In this way, we can enjoy the benefit of array type checking at compile time. In addition, in order to use them, the recipient of the array may not need to "shape" the object into the array.

(18) try to use interfaces instead of the abstract class. If you know that something is going to be a base class, then the * option should be to turn it into an interface. You need to turn it into an abstract (abstract) class only if you have to use a method definition or member variable. The interface mainly describes what the customer wants to do, while a class focuses on (or allows) specific implementation details.

(19) within the builder, only the work needed to set the object to the correct state is done. Avoid calling other methods as much as possible, as those methods may be overridden or cancelled by others, resulting in unpredictable results during the build process (see Chapter 7 for details).

(20) objects should not simply hold some data; their behavior should also be well defined.

(21) when creating a new class based on an off-the-shelf class, first select "New" or "author". This aspect should be considered only when one's own design requirements must be inherited. If inheritance is used in situations where new construction is allowed, the entire design becomes unnecessarily complex.

(22) inheritance and method coverage are used to represent the differences between behaviors, while fields are used to represent the differences between states. A very extreme example is to represent colors through inheritance from different classes, which should definitely be avoided: a "color" field should be used directly.

(23) to avoid trouble programming, make sure that each name corresponds to only one class wherever you point to your classpath. Otherwise, the compiler may first find another class with the same name and report an error message. If you suspect that you have a classpath problem, try searching for .class files with the same name at each starting point of the classpath.

(24) when using event "adapters" in Java 1.1 AWT, it is particularly easy to encounter a trap. If an adapter method is overwritten and the spelling method is not particularly particular, the result is to add a new method instead of overwriting the off-the-shelf method. However, because this is perfectly legal, you don't get any error hints from the compiler or run-time system-- it's just that the code doesn't work properly.

(25) use reasonable design scheme to eliminate "pseudo function". That is, if you only need to create one object of the class, don't restrict your use of the application in advance and add a "generate only one" comment. Consider encapsulating it in the form of an "only child". If there is a lot of scattered code in the main program to create your own objects, consider adopting a creative solution to encapsulate some of the code.

(26) be on guard against "analytical paralysis". Remember, in any case, know the status of the entire project in advance, and then examine the details. As a result of grasping the overall situation, we can quickly understand some unknown factors and prevent us from falling into "dead logic" when examining the details.

(27) be on guard against "premature optimization". Get it up and running first, and then think about getting faster-- but only if you have to do so and it turns out that there is a performance bottleneck in some part of the code. Unless you use special tools to analyze bottlenecks, you are likely to be wasting your time. The implicit cost of performance improvement is that your own code becomes difficult to understand and difficult to maintain.

(28) keep in mind that you spend much more time reading code than writing code. Clear-thinking designs can lead to programs that are easy to understand, but annotations, detailed explanations, and some examples are often of inestimable value. They are very important to yourself and to later people. If you still have doubts about this, imagine your own setbacks in trying to find useful information from online Java documents, which may convince you.

(29) if you think you have done a good analysis, design or implementation, please change your point of view slightly. Try inviting some outsiders-not necessarily experts, but people from other parts of the company. Ask them to take a completely fresh look at your work and see if they can identify problems that you once turned a blind eye to. In this way, we can often find out some key problems at the most suitable stage of modification, so as to avoid the loss of money and energy caused by solving the problem after the product is released.

(30) good design can pay off. In short, it usually takes a long time to find the most appropriate solution to a particular problem. But once you find the right way, your future job will be much easier and you won't have to struggle for hours, days or months. Our hard work will pay off (even incalculable). And because I put in a lot of painstaking efforts, and finally get an excellent design, the pleasure of success is also touching. Insist on resisting the temptation to finish hastily-the loss often outweighs the gain.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.