(1) The name of the class name should be capitalized. The first letters of fields, methods, and objects (handles) should be lowercase. For all identifiers, all words contained should be close to, and the first letters of the intermediate word. For example: ThisiisaclassNameThisisMethodorfieldName If a constant initialization character occurs in the definition, all letters in the Static Final base type identifier. This will sign a constant they belong to the compile period. The Java package (Package) belongs to a special situation: they are all lowercase letters, even if the intermediate words are true. For domain name extensions, such as COM, ORG, NET or EDU, all should be lowercase (this is also one of Java 1.1 and Java 1.2). (2) When creating a class for routine purposes, please take "classic form" and include definitions of the following elements: equals () hashcode () TOSTRING () Clone () Cloneable) Implement Serializable (3) Every class created by yourself is considered to place a main (), which contains code for testing the class. To use a class in a project, we don't have to delete the test code. If any form of change is made, it is convenient to return to the test. These codes can also be used as an example of how to use classes. (4) The method should be designed into a simple, functional unit, and use it to describe and implement a discontinuous class interface portion. Ideally, the method should be concise. If the length is large, it can be considered to split it into a shorter method in some way. This is also easy to use in the intra-class code (sometimes, the method must be very large, but they should only do the same thing). (5) When designing a class, please consider the customer programmer (the method of use should be very clear). Then, then the man who is located is considered to manage the management code (it is expected to make any form of modification, think about what method can be used to make them easier). (6) Enable the class as short as possible, and only solve a specific problem. Here is some suggestions for class design: ■ A complex switching statement: Considering the use of "multi-shape" mechanism ■ Number of many methods involves the type difference: Consider using several classes to achieve ■ Many member variables There is a big difference in the characteristics: Consider using several classes (7) let everything "private" --priVate. A portion of the library "publicization" (a method, class or a field, etc.) can never take it out. If you forced it, you may destroy someone else's existing code so that they have to rewrite and design. If you only publish yourself that you must publish, you can try to change anything else. In multi-threaded environments, privacy is a particularly important factor - only Private fields can be protected in the case of non-synchronous use. (8) We've been award "huge object syndrome". For some newbies that are accustomed to programming thinking, and initially involved in the OOP field, often like to write a sequential execution program, then embed it into one or two huge objects. Depending on the principle of programming, the object expression should be the concept of the application, not the application itself. (9) If there are not some unsightly programming, at least those code should be placed inside the class. (10) As long as the combination between classes and classes is found very close, it is necessary to consider whether the internal class is used to improve the coding and maintenance (see "Improved Code" in Section 14.1.2 of Chapter 14). (11) Add a comment as detailed as possible, and generate your own program document with the Javadoc comment documentation syntax.
(12) Avoid using "magic numbers", these numbers are difficult to cooperate with the code. If you need to modify it in the future, it will undoubtedly become a nightmare, because it doesn't know "100", it means "array size" or "other full things". So, we should create a constant and use the descriptive name with perseverance and use constant identifiers throughout the program. This makes the program more easily understand and easier maintenance. (13) When constructors and abnormalities, it is often desirable to re-discard any exception captured in the builder - if it causes the creation of that object to fail. In this way, the caller will not think that the object is created correctly, thus blindly continues. (14) When the customer programmer uses the object, if your class requests any clear work, consider placing the clear code in a good definition method, using a name similar to cleanup (), clearly indicating that yourself use. In addition, a Boolean mark can be placed in the class, indicating whether the object has been cleared. In the Finalize () method of the class, make sure the object has been cleared and has discarded a class (if not yet yet) from RuntimeException, indicating a programming error. Before taking a solution like this, make sure that Finalize () can work in its own system (you may need to call System.RunfinalizersoneXIT (TRUE) to ensure this line). (15) In a specific scope, if an object must be cleared (non-spam collection mechanism processing), use the following method: initialize the object; . (16) If you need to overwrite (cancel) finalize () during the initialization, please remember to call super.finalize () (if the Object belongs to our direct superclars, there is no reason). During the process of overwriting Finalize (), the call to Super.Finalize () should belong to the last action, and should not be the first action, which ensures that they remain valid when the basic class component is required. (17) When creating a size fixed object collection, transfer them to an array (if you are ready to return this collection from one method, it should be more In this way, we can enjoy the benefits of arrays in the compile period. In addition, for the use of them, the recipient of the array may not need to "style" into an array. (18) Try to use Interfaces, do not use the Abstract class. If a sample is known to be a basic class, then the first choice should turn it into an interface (interface). It is only necessary to turn it into an Abstract (Abstract) class only if the method definition or member variable is used. The interface mainly describes what customers want to do, and a class is committed to (or allowing) specific implementation details. (19) Inside the builder, only the work required to set the object to the correct state. Avoid calling other methods as much as possible because those methods may be overwritten or eliminated by others to produce unpredictable results during the construction process (see detailed description of Chapter 7). (20) Objects should not simply accommodate some data; their behavior should also be well defined. (21) When creating a new class on the basis of the current class, first select "New" or "Creation". This problem should only be considered if your design requirements must be inherited.
