设计
1. 优雅需要付出代价。
2. 先求能动在求快。
3. 记住“各个击破”原理。
4. 区分class开发者和class使用者。
5. 当你撰写class时，试着给予明了易懂的名称，减少不必要的注解。
6. 你的分析和设计必须让系统中的classes保持最少，也必须让其public interface保持最少，以及
让这些classes和其他classes之间的关联性（尤其是base classes）保持最少。
7. 让所有东西尽量自动化。
8. 在你撰写代码之前先写测试码，一边验证你的class是否设计完备。
9. 所有软件设计上的问题，都可以通过“引入额外的概念性简介层（conceptual）”加以简化。
10. 简介层（indirection）应该要有意义。
11. 让class尽可能微小而无法切割（atomic）。
12. 小心冗长的引数列（argument lists）。
13. 不要一再重复。
14. 小心switch语句或成串的if-else子句。
15. 从设计观点来看，请找出变动的事物，并使它和不变的事物分离。
16. 不要利用subclassing来扩充基本功能。
17. 少就是多。
18. 大声念出你的classes，确认它们符合逻辑。
19. 当你犹豫不决于继承（inheritance）或合成（组合，composition）时，请你
问问自己，是否需要向上转型（upcast）为基础型别。
20. 运用数据成员来表示数值的变化，运用经过复写的函数（overrided method）来代表行为的变化。
21. 小心重载（overriding）。
22. 使用异常体系（exception hierarchies）。
23. 有时候简单的聚合（aggregation）就够了。
24. 试着从客户程序员和程序维护者的角度思考。
25. 小心“巨大对象并发症”。
26. 如果你得用某种丑陋的方式来达成某个动作，请将丑陋的部分局限在某个class里头。
27. 如果你得使用某种不可移植方式来达成某个动作，请将它抽象化并局限于某个class里头。
28. 对象不应仅仅只用来持有数据。
29. 欲从既有的classes身上产生新的classes时，请以组合（composition）优先考量。
30. 运用继承和函数覆写机制来展现行为上的差异，运用fields（数据成员）来展现状态上的差异。
31. 当心变异性（ariance）。
32. 注意继承上的限制。
33. 使用设计模式（design pattern）来减少“赤裸裸无加掩饰的机能（naked functionality）”。
34. 当心“因分析而导致的瘫痪（analysis paralysis）”。
35. 当你认为你已经获得一份优秀的分析、设计或实现时，请试着加以演练。
实现（implementation）
36. 一般来说，请遵守Sun的程序编写习惯。
37. 无论使用何种编程风格，如果你的团队能够加以标准化，那么的确会带来显著效果。
38. 遵守标准的大小写规范。
39. 不要自己发明“装饰用的”private数据成员名称。
40. 当你撰写通用性class时，请遵守正规形式（canonical form）。
41. 对于那些“取得或改变private数据值”的函数，请使用JavaBeans的“get”、“set”、“is”等命名习惯。
42. 对于你所撰写的每一个class，请考虑为它加入static public test（），其中含有class功能测试码。
43. 有时候你需要通过继承，才得以访问base class的protected成员。
44. 避免纯粹为了效率考量而使用final函数。
45. 如果两个classes因某种功能性原因而产生了关联（例如容器containers和迭代器iterators），那么
请试着让其中某个class成为另一个class的内隐类（inner class）。
46. 任何时候你都要注意那些高度耦合（coupling）的classes。请考虑内隐类（inner classes）
为程序撰写和维护带来的好处。
47. 不要成为“过早最优化”的牺牲品。
48. 让范围（作用域，scope）尽可能愈小愈好，这么一来对象的可视范围和寿命都将尽可能地小。
49. 使用Java标准程序库提供的容器。
50. 对一个强固的（robust）程序而言，每一个组成都必须强固。
51. 宁可在编译期发生错误，也不要在执行期发生错误。
52. 当心冗长的函数定义。
53. 尽可能保持“private”。
54. 大量运用注解，并使用javadoc的“注解文档语法”来产生程序的说明文档。
55. 避免使用“魔术数字”，也就是那种写死在程序代码里头的数字。
56. 撰写构造函数时，请考虑异常状态。
57. 如果你的class需要在“客户程序员用完对象”后进行清理动作，请将清理动作放到单一而定义明确的函数中。
58. finalize()只可用于对象死亡条件的检验，俾有益于调试。
59. 如果某个对象在某个特定范围（scope）内必须被清理（cleaned up），而不是被垃圾回收机制收回，
请使用一下方法：将对象初始化，成功后立刻进入拥有finally子句的try区段块。finally子句会引发清理动作。
60. 当你在继承过程中腹泻了finalize()，请记住调用super。finalize()。
61. 当你撰写固定大小的对象容器，请将它们转换为数组——尤其是从某个函数返回此一容器时。
62. 在interface（接口）和abstract class（抽象类）之间，优先前者。
63. 在构造函数中只做唯一必要动作：将对象设定至适当状态。
64. 为了避免一个十分令人泄气的经验，请确认你的classpath中的每个名称，都只有一个未被放到
packages里头的class。
65. 留意一不小心犯下的重载（overriding）错误。
66. 当心过早最优化。
67. 记住，程序代码被阅读的时间多于它被撰写的时间。
840
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
