Java programming principles

Design

 

1. Elegance requires a price.

2. Please be proactive.

3. Remember the principle of "cracking.

4. differentiate between class developers and class users.

5. When you write a class, try to give clear and easy-to-understand names to reduce unnecessary annotations.

6. Your analysis and design must minimize the number of classes in the system, public interfaces, and

Minimize the associations between these classes and other classes (especially base classes.

7. Make everything as automated as possible.

8. Write the test code before writing the code to verify whether your class is fully designed.

9. All software design issues can be simplified by introducing an additional conceptual profile layer (conceptual.

10. The introduction layer (indirection) should be meaningful.

11. Make the class as small as possible and cannot be cut (atomic ).

12. Be careful with the lengthy cited series (argument lists ).

13. Do not repeat multiple times.

14. Be careful with the switch statement or the if-else clause.

15. From the design point of view, please find the changed things and separate them from the unchanged things.

16. Do not use subclassing to expand basic functions.

17. Less is more.

18. Read your classes out loud and confirm that they are logical.

19. When you hesitate to inherit or combine (composition), please

Ask yourself if you want to convert to upcast as the basic type.

20. Data members are used to represent changes in values, and overrided methods are used to represent changes in behavior.

21. overriding ).

22. exception hierarchies ).

23. Sometimes simple aggregation is enough.

24. Try to think from the perspective of client programmers and program maintainers.

25. Be careful with "huge object complications ".

26. If you have to implement an action in an ugly way, please limit the ugly part to a class.

27. If you have to use some non-portable method to achieve an action, abstract it and limit it to a class.

28. Objects should not only be used to hold data.

29. When you want to generate a new classes from an existing classes, consider the combination first.

30. Use inheritance and function overwriting mechanisms to show behavioral differences and fields (data member) to show status differences.

31. Beware of variability ).

32. Pay attention to the limitations on inheritance.

33. Use the design pattern to reduce "naked and unmasked functions (naked functionality )".

34. Be careful with "analysis paralysis )".

35. When you think you have obtained an excellent analysis, design, or implementation, try to practice it.

 

 

Implementation)

 

36. In general, follow Sun's programming habits.

37. Whatever programming style you use, if your team can standardize it, it will indeed bring significant results.

38. comply with the standard case sensitivity specification.

39. Do not create the "decorative" private data member name by yourself.

40. When writing a universal class, follow the canonical form ).

41. For those functions that "get or change private data values", use the naming conventions of JavaBeans such as "get", "set", and "is.

42. For every class you write, consider adding static public test () to it, which contains the class function test code.

43. Sometimes you need to inherit to access the protected member of the base class.

44. Avoid using final functions purely for efficiency considerations.

45. If two classes are associated for some functional reason (for example, container containers and iterators ),

Try to make one of the classes the inner class of another class ).

46. always pay attention to those highly coupled classes. Consider inner classes)

Benefits for program writing and maintenance.

47. Do not be the victim of "premature optimization.

48. Make the scope as smaller as possible, so that the visible range and lifetime of the object will be as small as possible.

49. Use the container provided by the Java standard library.

50. For a strong (robust) program, each group of Chengdu must be strong.

51. It is preferred that errors occur during compilation and not during execution.

52. Be careful with lengthy function definitions.

53. Keep "private" as much as possible ".

54. extensively use annotations and use javadoc's "annotation Document Syntax" to generate program instructions.

55. Avoid using "magic numbers", that is, the numbers that are written to the program code.

56. Consider the exception status when writing the constructor.

57. If your class needs to be cleaned up after "the client programmer has used up the object", put the cleanup action in a single and clearly defined function.

58. finalize () can only be used to test the death condition of an object, which is useful for debugging.

59. If an object must be cleaned up within a specific scope, rather than being reclaimed by the garbage collection mechanism,

Use the following method: Initialize the object and immediately enter the try block with the finally clause. The finally Clause triggers a cleanup action.

60. When you have diarrhea finalize () during the inheritance process, remember to call super. Finalize ().

61. When you write a fixed-size object container, convert them into Arrays-especially when a function returns this container.

62. The former is preferred between the interface (interface) and abstract class (abstract class.

63. make only the necessary actions in the constructor: Set the object to the appropriate State.

64. To avoid a very frustrating experience, check that each name in your classpath has only one

Class in packages.

65. Pay attention to an accidental overload error.

66. Be careful about premature optimization.

67. Remember, the program code is read more time than it was written.