Effective Java 读书笔记(6)

38，检查参数的正确性。如果方法对传进来的参数有限制，那就对参数进行检查，如果参数不符合要求，那就尽早的抛出异常。如果不这样的话，那造成的错误可能会在很奇怪的地方出现，很难排查。但是如果这个检查比较耗资源，可以考虑不检查，还有种情况，是方法内部有隐含的检查，比如Collections.sort(List<T> list)，这个方法并没有在签名里限制参数一定要实现Comparable接口，但是它内部会先把参数cast成Comparable，然后再调用compareTo方法。所以它不需要检查参数是否实现了Comparable接口，最终出错时的提示跟预先检查发现出错给的提示是一样的。
39，当需要的时候，做防御性复制。不考虑反射这些变态的手法，至少不要给你的用户提供合法的破坏途径。对于传入的参数，如果要做防御性复制，要在检查参数正确性之前做，如果反过来，可能你检查参数正确性的时候还没有问题，但是你复制的时候就有问题了。如果你的内部字段是可变的，那传出去的时候也要做防御性复制。前几天公司有个同事就犯了很愚蠢的错误，自己写的函数改了Date类型参数的值，还很奇怪为什么执行了这个函数之后，Date类型的值也会变。当然他的问题就多了，他甚至不知道

Date d1 = new Date();
 Date d2 = d1;

究竟有几个Date对象。
40，仔细设计函数的签名。主要是以下几条
1）仔细选择函数的名字
2）不要提供太多的便利方法
3）避免太长的参数列表，最好不要超过4个。想起当年学C的时候，第一次看到WinMain函数的震撼了，整整12个参数啊。缩减过长的参数列表有3种方法，1是把方法分解成多个小方法，2是创建辅助类，比如把纸牌的花色和点数封装成一个纸牌类，3就是第2条中提到过的Builder模式。
4）在参数列表中使用接口而不是类。但是也不要过度了，以前见过一个项目，返回的明明就是List，返回值那里非要写Collection而不是List。
5）用两个元素的enum取代boolean
41，谨慎的使用重载。对于重载(overload)方法的选择是在编译时决定的，而覆盖(override)的方法的选择是在运行时决定的。自从JDK1.5引入auto box/unbox之后，List的remove(int)和remove(E)就有了歧义，可见一个系统变大了之后，向里面添加新的特性可能会造成很奇怪的问题。
42，谨慎的使用varargs。varargs是很好，不过也不能滥用，该用数组的地方还是老老实实用数组好了。varargs的引入也导致Arrays.asList方法的行为出现了变化。
43，返回空的数组或者集合，而不是null。第一次见到这么用，还是在用iBatis的时候，它的queryForList方法在查不到结果的时候，也会返回一个空的List。
44，对于暴露出来的方法，用javadoc来写注释。在JDK 1.5之后，还引入了{@code}和{@literal}两个标记。