1. The first letter of the class name should be capitalized. The first letter of fields, methods, and objects (handles) should be lowercase. As with all identifiers, all words contained within it should be close together, with the first letter of the intervening word capitalized. For example:
Copy the code as follows: ThisIsAClassName
thisIsMethodOrFieldName
If a constant initializer character appears in the definition, capitalize all letters in the static final basic type identifier. This will mark them as compile-time constants.
Java packages are a special case: they are all lowercase, even the middle words. For domain name extension names, such as com, org, net or edu, etc., all should 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, please adopt the "classic form" and include definitions of the following elements:
Copy the code code as follows:
equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable
3. For each class you create, consider placing a main(), which contains the code for testing that class. To use classes from a project, we don't have to delete the test code. If changes of any kind are made, it is easy to return to testing. The code also serves as an example of how to use classes.
4. The method should be designed into a brief, functional unit, which can be used to describe and implement a discontinuous class interface part. Ideally, the approach should be concise and to the point. If the length is large, consider dividing it into shorter pieces in some way. Doing this also facilitates reuse of code within a class (sometimes, methods must be very large, but they should still only do the same thing).
5. When designing a class, please put yourself in the shoes of the client programmer (the method of using the class should be very clear). Then, put yourself in the shoes of the person managing the code (anticipate what kinds of changes are likely to be made, and think about ways to make them simpler).
6. Make the class as short and concise as possible, and only solve a specific problem. Here are some suggestions for class design:
1. A complex switch statement: consider using the "polymorphic" mechanism
2. A large number of methods involve operations with greatly different types: consider using several classes to implement them separately.
3. Many member variables have very different characteristics: consider using several classes
7. Make everything as "private" as possible. You can make a part of the library "public" (a method, a class, a field, etc.) so that it can never be taken 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 feel free to change anything else. In multi-threaded environments, privacy is a particularly important factor. Only private fields can be protected against unsynchronized use.
8. Be wary of “giant object syndrome”. For some novices who are accustomed to sequential programming thinking and are new to the OOP field, they often like to write a sequential execution program first, and then embed it into 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 unsightly programming, you should at least put the code inside a class.
10. Whenever you find that classes are very closely integrated, you need to consider whether to use internal classes to improve coding and maintenance work (see "Improving Code with Internal Classes" in Chapter 14, Section 14.1.2).
11. Add comments as carefully as possible and use javadoc comment document syntax to generate your own program documentation.
12. Avoid using "magic numbers". These numbers are difficult to fit well with the code. If you need to modify it in the future, it will undoubtedly become a nightmare, because you have no idea whether "100" refers to "array size" or "something else entirely." Therefore, we should create a constant, give it a convincing and descriptive name, and use constant identifiers throughout the program. This makes the program easier to understand and maintain.
13. When it comes to builders and exceptions, you usually want to re-throw any exception caught in the builder if it caused the creation of that object to fail. This way the caller won't continue blindly thinking that the object has been created correctly.
14. After the client programmer has finished using the object, if your class requires any cleanup work, consider placing the cleanup code in a well-defined method, using a name like cleanup() to clearly indicate your use. In addition, a boolean flag can be placed within the class to indicate whether the object has been cleared. In the class's finalize() method, make sure that the object has been cleared and that a class that inherits from RuntimeException has been discarded (if it hasn't already), thus indicating a programming error. Before taking a solution like this, make sure finalize() works on your 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 processed by the garbage collection mechanism), please use the following method: initialize the object; if successful, immediately enter a try block containing a finally clause to start the cleanup work .
16. If you need to override (cancel) finalize() during the initialization process, please remember to call super.finalize() (if Object belongs to our direct super class, this is not necessary). In the process of overriding finalize(), the call to super.finalize() should be the last action, not the first action, to ensure that the base class components are still valid when they are needed.
17. When creating fixed-size object collections, transfer them to an array (especially if you plan to return this collection from a method). In this way, we can enjoy the benefits of array type checking at compile time. Furthermore, the recipient of the array may not need to "cast" the object into the array in order to use them.
18. Try to use interfaces instead of abstract classes. If you know something is going to be a base class, your first option should be to turn it into an interface. Only when you have to use method definitions or member variables, you need to turn it into an abstract class. An interface basically describes what the client wants to do, while a class is dedicated to (or allows for) specific implementation details.
19. Inside the builder, do only the work required to put the object into the correct state. Whenever possible, avoid calling other methods, as those methods may be overridden or canceled by others, producing 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 existing class, please first select "New" or "Create". This issue should only be considered if your own design requirements must be inherited. If inheritance is used where new creation is allowed, the entire design becomes unnecessarily complex.
22. Use inheritance and method coverage to express the difference between behaviors, and use fields to express the difference between states. A very extreme example is to represent colors through inheritance from different classes, which should definitely be avoided: use a "color" field directly.
23. To avoid trouble when programming, please ensure that each name corresponds to only one class wherever your class path points to. Otherwise, the compiler might first find another class with the same name and report an error message. If you suspect that you have encountered a class path problem, please try searching for a .class file with the same name at each starting point of the class path.
24. When using event "adapters" in Java 1.1 AWT, it is particularly easy to encounter a trap. If an adapter method is overridden and the spelling method is not particularly particular, the final result will be to add a new method instead of overriding the existing method. However, since this is perfectly legal, you won't get any error messages from the compiler or runtime system, but your code will just behave incorrectly.
25. Use reasonable design solutions to eliminate "pseudo functions". That is, if you only need to create one object of the class, don't limit yourself to the application in advance and add a "generate only one of them" comment. Please consider encapsulating it into an "only child" form. If you have a lot of scattered code in the main program that is used to create your own objects, consider adopting a creative solution to encapsulate this code.
26. Be wary of "paralysis by analysis". Remember, no matter what, you need to understand the status of the entire project in advance and then examine the details. Because you have a grasp of the overall situation, you can quickly recognize some unknown factors and prevent yourself from falling into "dead logic" when examining details.
27. Be wary of "premature optimization". Make it run first, think about getting faster later, but only optimize if you have to and if it's proven that there is a performance bottleneck in some part of the code. Unless you use specialized tools to analyze bottlenecks, you are probably wasting your time. The implicit cost of performance improvements is that your code becomes harder to understand and harder to maintain.
28. Remember, you spend much more time reading code than writing it. A clear design results in an easy-to-understand program, but comments, careful explanations, and a few examples are often invaluable. They are very important, both to yourself and to those who follow you. If you still doubt this, just imagine your frustration trying to find useful information in online Java documentation, and you may be convinced.
29. If you think you have performed a good analysis, design or implementation, please change your thinking perspective slightly. Try inviting some outsiders, not necessarily experts, but people from other parts of the company. Ask them to look at your work with completely fresh eyes and see if they can spot problems that you were blind to. By adopting this method, we can often identify some key problems at the stage that is most suitable for modification, and avoid the loss of money and energy caused by solving problems after the product is released.
30. Good design can bring the greatest returns. In short, it often takes a long time to find the most appropriate solution to a given problem. But once you find the right method, your future work will be much easier, and you won’t have to endure hours, days, or months of painful struggle. Our hard work will bring the greatest rewards (even immeasurable ones). And because I put a lot of effort into it, I finally got an excellent design plan, and the thrill of success is also exciting. Resist the temptation to rush through the work, which is often not worth the effort.