Java 编程指南

详情：https://github.com/muyuxx/onJava8/blob/master/docs/book/Appendix-Programming-Guidelines.md

1、优雅总是会有回报。
2、先让它工作，然后再让它变快。
3、记住“分而治之”的原则。
4、将类创建者与类用户（客户端程序员）分开。
5、创建类时，给类起个清晰的名字，就算不需要注释也能理解这个类。
6、你的分析和设计必须至少能够产生系统中的类、它们的公共接口以及它们与其他类的关系，尤其是基类。
7、让一切自动化。
8、在编写类之前，先编写测试代码，以验证类的设计是完善的。
9、所有的软件设计问题，都可以通过引入一个额外的间接概念层次（extra level of conceptual indirection）来解决。
10、间接（indirection）应具有意义（与准则9一致）。
11、使类尽可能原子化。
12、注意长参数列表。
13、不要重复自己。
14、注意switch语句或链式if-else子句。
15、从设计的角度，寻找和分离那些因不变的事物而改变的事物。
16、不要通过子类扩展基本功能。
17、少即是多。
18、大声读出你的类以确保它们合乎逻辑。
19、在需要在继承和组合之间作决定时，问一下自己是否必须向上转换为基类型。
20、注意重载。
21、使用异常层次结构，最好是从标准Java异常层次结构中的特定适当类派生。
22、有时简单的聚合可以完成工作。
23、考虑客户程序员和维护代码的人的观点。
24、注意“巨型对象综合症”（giant object syndrome）。
25、如果你必须做一些丑陋的事情，至少要把类内的丑陋本地化。
26、如果必须做一些不可移植的事情，那就对这个事情做一个抽象，并在一个类中进行本地化。
27、对象不应该仅仅只是持有一些数据。
28、在从现有类创建新类时首先选择组合。
29、使用继承和覆盖方法来表达行为的差异，而不是使用字段来表示状态的变化。
30、注意协变（variance）。
31、在继承期间注意限定（limitation）。
32、使用设计模式来消除“裸功能”（naked functionality）。
33、注意“分析瘫痪”（analysis paralysis）。
34、如果认为自己有很好的分析，设计或实施，请做一个演练。

实现

35、遵循编码惯例。
36、无论使用何种编码风格，如果你的团队（甚至更好是公司）对其进行标准化，它就确实会产生重大影响。
37、遵循标准的大写规则。
38、不要创建自己的“装饰”私有字段名称。
39、在创建一般用途的类时，遵循“规范形式”。
40、对读取和更改私有字段的方法使用“get”，“set”和“is”命名约定。
41、对于所创建的每个类，请包含该类的JUnit测试。
42、有时需要继承才能访问基类的protected成员。
43、为了提高效率，避免使用final方法。
44、如果两个类以某种功能方式相互关联（例如集合和迭代器），则尝试使一个类成为另一个类的内部类。
45、只要你注意到类似乎彼此之间具有高耦合，请考虑如果使用内部类可能获得的编码和维护改进。
46、不要成为过早优化的牺牲品。
47、保持作用域尽可能小，以便能见度和对象的寿命尽可能小。
48、使用标准Java库中的集合。
49、为使整个程序健壮，每个组件必须健壮。
50、编译时错误优于运行时错误。
51、注意长方法定义。
52、保持“尽可能私有”。
53、大量使用注释，并使用Javadoc commentdocumentation语法生成程序文档。
54、避免使用“魔法数字”。
55、在创建构造方法时，请考虑异常。
56、在构造方法内部，只需要将对象设置为正确的状态。
57、如果类在客户端程序员用完对象时需要进行任何清理，请将清理代码放在一个明确定义的方法中，并使用像 dispose() 这样的名称来清楚地表明其目的。
58、finalize() 的职责只能是验证对象的“终止条件”以进行调试。
59、如果必须在特定范围内清理对象（除了通过垃圾收集器），请使用以下准则： 初始化对象，如果成功，立即进入一个带有 finally 子句的 try 块，并在 finally中执行清理操作。
60、在继承期间覆盖 finalize() 时，记得调用 super.finalize()。
61、创建固定大小的对象集合时，将它们转换为数组， 尤其是在从方法中返回此集合时。
62、优先选择接口，而不是抽象类。
63、为了避免非常令人沮丧的经历，请确保类路径中的每个名称只对应一个不在包中的类。
64、注意意外重载。
65、注意过早优化。
66、请注意，相比于编写代码，代码被阅读的机会更多。