(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. E.g:
THISACLASSNAME
THISMETHODORFIELDNAME
If a constant initialization character occurs in the definition, all letters in the Static Final base type identifier are capitalized. 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 the definition of the following elements:
Equals ()
Hashcode ()
Tostring ()
Clone () (Implement Cloneable)
Implement serializable
(3) For each class created by yourself, it 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. Below is some suggestions for class design:
■ A complex switching statement: Consider using the "multi-shape" mechanism
■ Number of many methods involve a very large type of difference: Consider using several classes to achieve separately
■ Many member variables have a big difference in characteristics: consider using several classes
(7) Let everything "private" as much as possible --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. 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. If inheritance is allowed to be used, the entire design will become unnecessarily complicated.
(22) Use inheritance and method coverage to represent the difference between behavior, and use the field representation of the difference between the state. A very extreme example is a color through inheritance of different classes, which is absolutely avoided: a "color" field should be used directly.
(23) In order to avoid the trouble, please ensure that each name is only a class anywhere in its own path. Otherwise, the compiler may find another class of the same name and report the error message. If you suspect that you have encountered a classpath problem, try to search each of the starting points of the class path to search the same name .class file.
(24) When using an event "adapter" in Java 1.1 AWT, it is especially easy to touch a trap. If an adapter method is covered, the spelling method is not particularly particular, and the final result is the new addition method, not to overwrite the ready-made method. However, since this is completely legitimate, no error prompt from the compiler or runtime system - only the job work is not normal.
(25) eliminate "pseudo function" with a reasonable design. That is, if you only need to create an object of the class, don't limit your use of your application in advance, and add a "only one of them" comments. Consider encapsulating it into a "single child" form. If there is a large amount of scattered code in the main program, it is used to create its own object, consider adopting a creative solution, encapsulate some code.
(26) Be wary of "Analysis Palph". Remember, no matter how to understand the situation of the entire project in advance, go to examine the details. Since the overall situation is grasped, some factors that you don't know quickly will prevent it in "dead logic" when the details are visited.
(27) Be wary of "premature optimization". First let it run, and then consider getting faster - but it should be optimized when you have to do this, and it is proven to have a performance bottleneck in a part of the code. Unless the bottleneck is analyzed with a special tool, it is likely that it is a waste of your own time. The implicit price of performance is difficult to understand, and it is difficult to maintain.
(28) Remember that the time to read the code is much more than the time of writing code. Clear design of ideas can get programs that are easy to understand, but annotations, meticulous interpretations, and some examples often have an inevitable value. Whether it is your own, it is quite important to later people, they are all right. If you still have doubts about this, please try to try to find a setback from the Java document to find useful information, which may be convincing.
(29) If you think that you have made good analysis, design or implementation, then replace the angle of thinking slightly. Try to invite some foreign people - not necessarily an expert, but it can be from the other departments of the company. Please examine your work with a completely fresh vision and see if you can find out what you know. In this way, it is often possible to find some key issues in the most suitable modification, avoiding the loss of money and energy caused by the problem after the product is released.
(30) Good design can bring the biggest return. Briefly, for a specific issue, it usually takes a long time to find the most appropriate solution. But once you find the right way, you will be more relaxed in the future, no need to experience a few days, days or months. Our efforts will bring the biggest return (or even unrecognizable). And since I poured a lot of heart blood, I finally got an outstanding design, and the thrill of success was also very exciting. Adhere to the temptation of the completion of herbs - the same is often unpaid (3) Every class created by yourself, considering the placement of MAIN (), which contains code for testing that class. To use a class in a project, we don't have to delete the test code. If any form is made, it is convenient to return to the test. These codes can also be used as an example of how to use classes.
This is Absolutly Bad!
(4) The method should be designed to simply, functional units, 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 reciprocal 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 are some suggestions for class design:
■ A complex switching statement: Consider using the "multi-shape" mechanism
■ Number of many methods involve a very large type of difference: Consider using several classes to achieve separately
■ Many member variables have a big difference in characteristics: consider using several classes
(7) Let everything "private" as much as possible --Private. A portion of the library "publicization" (a method, class or a field, etc.) can never take it out. If you are forcibly, you may break the existing code of others 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.
Not Necessary, Pretotect or Package Level Also Fine In Most Case
(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 in a class of a class.
(10) As long as the combination between classes and classes is found very close, consider whether to use internal classes, thereby improving coding and maintenance (see "Improved code for internal class" in Chapter 14 14.1.2 ") .
(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. So, we should create a constant and use it with persuasive description name 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 object's creation failure. 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-useful processing mechanism processing), use the following method: initialize the object; Clear work.
(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 overwrinkting 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 a party, you should do this). In this way, we can enjoy the benefits of the array in the compilation 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 you are known to be a basic class, 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.
They is Total Diffrent,
(19) Inside the builder, only the work required to set the object to the correct state. Woke other methods as much as possible, because those methods may be covered or canceled 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 you need to inherit it. If inheritance is allowed to be used, the entire design will become unnecessarily complicated. (22) Use inheritance and method coverage to represent the difference between behavior, and use the field representation of the difference between the state. A very extreme example is a color through inheritance of different classes, which is absolutely avoided: a "color" field should be used directly.
(23) In order to avoid the trouble, please ensure that each name is only a class anywhere in its own path. Otherwise, the compiler may find another class of the same name and report the error message. If you suspect that you have encountered a classpath problem, try to search each of the starting points of the class path to search the same name .class file.
Classpath Is Not That Simple
(24) When using an event "adapter" in Java 1.1 AWT, it is especially easy to touch a trap. If an adapter method is covered, the spelling method is not particularly particular, and the final result is a new addition method, not to override ready-made methods. However, since this is completely legal, no error prompt from the compiler or runtime system - only the job work is not normal.
(25) eliminate "pseudo function" with a reasonable design. That is, if you only need to create a pair of objects, don't limit your use of your application in advance, and add a "only one of them" comments. Consider encapsulating it into a "single child" form. If there is a large amount of scattered code in the main program, it is used to create its own object, consider adopting a creative solution, encapsulate some code.
(26) Be wary of "Analysis Palph". Remember, no matter how to understand the situation of the entire project in advance, go to examine the details. Since the overall situation is grasped, some factors that you don't know quickly will prevent it in "dead logic" when the details are visited.
(27) Be wary of "premature optimization". First let it run, and then consider getting faster - but it should be optimized when you have to do this, and it is proven to have a performance bottleneck in a part of the code. Unless the bottleneck is analyzed with a special tool, it is likely that it is a waste of your own time. The implicit price of performance is difficult to understand, and it is difficult to maintain.
But Know Early and Design Better At First Is Always Necesary, or else
You Die
(28) Remember that the time to read the code is much more than the time of writing code. Clear design of ideas can get programs that are easy to understand, but annotations, meticulous interpretations, and some examples often have an inevitable value. Whether it is your own, it is quite important to later people, they are all right. If you still have doubts about this, please try to try to find a setback when you find useful information from the online Java document, which may be convincing.
(29) If you think that you have made good analysis, design or implementation, then replace the perspective angle. Try to invite some foreign people - not necessarily an expert, but it can be from the other departments of the company. Please examine your work with a full fresh eye to see if you can find out what you know. In this way, it is often possible to find some key issues in the most suitable modification, avoiding the loss of money and energy caused by the problem after the product is released.
