6.设计API时永远不要返回空(null)数组或List
　　尽管在一些情况下方法返回值为null是可以的，但是绝不要返回空数组或空集合！请看 java.io.File.list()方法，它是这样设计的：
　　此方法会返回一个指定目录下所有文件或目录的字符串数组。如果目录为空(empty)那么返回的数组也为空(empty)。如果指定的路径不存在或发生I/O错误，则返回null。
　　因此，这个方法通常要这样使用：
　　File directory = // ...
　　if (directory.isDirectory()) {
　　String[] list = directory.list();
　　if (list != null) {
　　for (String file : list) {
　　// ...
　　}
　　}
　　}
　　大家觉得null检查有必要吗？大多数I/O操作会产生IOExceptions，但这个方法却只返回了null。Null是无法存放I/O错误信息的。因此这样的设计，有以下3方面的不足：
　　Null无助于发现错误
　　Null无法表明I/O错误是由File实例所对应的路径不正确引起的
　　每个人都可能会忘记判断null情况
　　以集合的思维来看待问题的话，那么空的(empty)的数组或集合是对“不存在”的佳实现。返回空(null)数组或集合几乎是无任何实际意义的，除非用于延迟初始化。
　　规则：返回的数组或集合不应为null。
　　7. 避免状态，使用函数
　　HTTP的好处是无状态。所有相关的状态在每次请求和响应中转移。这是REST命名的本质：含状态传输(Representational state transfer)。在Java中这样做也很赞。当方法接收状态参数对象的时候从规则2的角度想想这件事。如果状态通过这种对象传输，而不是从外边操作状态，那么事情将会更简单。以JDBC为例。下述例子从一个存储的程序中读取一个光标。
　　CallableStatement s =
　　connection.prepareCall("{ ? = ... }");
　　// Verbose manipulation of statement state:
　　s.registerOutParameter(1， cursor);
　　s.setString(2， "abc");
　　s.execute();
　　ResultSet rs = s.getObject(1);
　　// Verbose manipulation of result set state:
　　rs.next();
　　rs.next();
　　这使得JDBC API如此的古怪。每个对象都是有状态的，难以操作。具体的说，有两个主要的问题：
　　在多线程环境很难正确的处理有状态的API
　　很难让有状态的资源全局可用，因为状态没有被描述
　　规则：更多的以函数风格实现。通过方法参数转移状态。极少操作对象状态。
　　8. 短路式 equals()
　　这是一个比较容易操作的方法。在比较复杂的对象系统中，你可以获得显著的性能提升，只要你在所有对象的equals()方法中首先进行相等判断:
　　@Override
　　public boolean equals(Object other) {
　　if (this == other) return true;
　　// 其它相等判断逻辑...
　　}
　　注意，其它短路式检查可能涉及到null值检查，所以也应当加进去:
　　@Override
　　public boolean equals(Object other) {
　　if (this == other) return true;
　　if (other == null) return false;
　　// Rest of equality logic...
　　}
　　规则: 在你所有的equals()方法中使用短路来提升性能。
　　9. 尽量使方法默认为final
　　有些人可能不同意这一条，因为使方法默认为final与Java开发者的习惯相违背。但是如果你对代码有完全的掌控，那么使方法默认为final是肯定没错的：
　　如果你确实需要覆盖（override）一个方法（你真的需要？），你仍然可以移除final关键字
　　你将永远不会意外地覆盖（override）任何方法
　　这特别适用于静态方法，在这种情况下“覆盖”（实际上是遮蔽）几乎不起作用。我近在Apache Tika中遇到了一个很糟糕的遮蔽静态方法的例子。看一下：
　　TaggedInputStream.get(InputStream)
　　TikaInputStream.get(InputStream)
　　TikaInputStream扩展了TaggedInputStream，以一种相对不同的实现遮蔽了它的静态get()方法。
　　与常规方法不同，静态方法不能互相覆盖，因为调用的地方在编译时绑定了静态方法调用。如果你不走运，你可能会意外获得错误的方法。
　　规则：如果你完全掌控你的API，那么使尽可能多的方法默认为final。
　　10. 避免方法(T…)签名
　　在特殊场合下使用“accept-all”变量参数方法接收一个Object…参数没有错的：
　　void acceptAll(Object... all);
　　编写这样的方法为Java生态系统带来一点儿JavaScript的感觉。当然你可能想要根据真实的情形限制实际的类型，比如String…。因为你不想要限制太多，你可能会认为用泛型T取代Object是一个好想法：
　　void acceptAll(T... all);
　　但是不是。T总是会被推断为Object。实际上你可能仅仅认为上述方法中不能使用泛型。更重要的是你可能认为你可以重载上述方法，但是你不能：
　　void acceptAll(T... all);
　　void acceptAll(String message， T... all);
　　这看起来好像你可以可选地传递一个String消息到方法。但是这个调用会发生什么呢？
　　acceptAll("Message"， 123， "abc");
　　编译器将T推断为<? extends Serializable & Comparable<?>>，这将会使调用不明确！
　　所以无论何时你有一个“accept-all”签名（即使是泛型），你将永远不能类型安全地重载它。API使用者可能仅仅在走运的时候才会让编译器“偶然地”选择“正确的”方法。但是也可能使用accept-all方法或者无法调用任何方法。
　　规则: 如果可能，避免“accept-all”签名。如果不能，不要重载这样的方法。
　　结论
　　Java是一个野兽。不像其它更理想主义的语言，它慢慢地演进为的样子。这可能是一件好事，因为以Java的开发速度已经有成百上千个警告，而且这些警告只能通过多年的经验去把握。