这是一个比Josh Bloch的Effective Java规则更精妙的10条Java编码实践的列表。和Josh Bloch的列表容易学习并且关注日常情况相比，这个列表将包含涉及API/SPI设计中不常见的情况，可能有很大影响。
　　我在编写和维护jOOQ(Java中内部DSL建模的SQL)时遇到过这些。作为一个内部DSL，jOOQ大限度的挑战了Java的编译器和泛型，把泛型，可变参数和重载结合在一起，Josh Bloch可能不会推荐的这种太宽泛的API。
　　让我与你分享10个微妙的Java编码佳实践：
　　1. 牢记C++的析构函数
　　记得C++的析构函数？不记得了？那么你真的很幸运，因为你不必去调试那些由于对象删除后分配的内存没有被释放而导致内存泄露的代码。感谢Sun/Oracle实现的垃圾回收机制吧！
　　尽管如此，析构函数仍提供了一个有趣的特征。它理解逆分配顺序释放内存。记住在Java中也是这样的，当你操作类析构函数语法：
　　使用JUnit的@Before和@After注释
　　分配，释放JDBC资源
　　调用super方法
　　还有其他各种用例。这里有一个具体的例子，说明如何实现一些事件侦听器的SPI：
　　@Override
　　public void beforeEvent(EventContext e) {
　　super.beforeEvent(e);
　　// Super code before my code
　　}
　　@Override
　　public void afterEvent(EventContext e) {
　　// Super code after my code
　　super.afterEvent(e);
　　}
　　臭名昭著的哲学家餐问题是另一个说明它为什么重要的好例子。 关于哲学家用餐的问题，请查看链接：
　　http://adit.io/posts/2013-05-11-The-Dining-Philosophers-Problem-With-Ron-Swanson.html
　　规则：无论何时使用before/after， allocate/free， take/return语义实现逻辑时，考虑是否逆序执行after/free/return操作。
　　2. 不要相信你早期的SPI演进判断
　　向客户提供SPI可以使他们轻松的向你的库/代码中注入自定义行为的方法。当心你的SPI演进判断可能会迷惑你，使你认为你 (不)打算需要附加参数。 当然，不应当过早增加功能。但一旦你发布了你的SPI，一旦你决定遵循语义版本控制，当你意识到在某种情况下你可能需要另外一个参数时，你会真的后悔在SPI中增加一个愚蠢的单参数的方法:
　　interface EventListener {
　　// Bad
　　void message(String message);
　　}
　　如果你也需要消息ID和消息源，怎么办？API演进将会阻止你向上面的类型添加参数。当然，有了Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策：
　　interface EventListener {
　　// Bad
　　default void message(String message) {
　　message(message， null， null);
　　}
　　// Better?
　　void message(
　　String message，
　　Integer id，
　　MessageSource source
　　);
　　}
　　注意，不幸的是，defender方法不能使用final修饰符。
　　但是比起使用许多方法污染你的SPI，使用上下文对象(或者参数对象)会好很多。
　　interface MessageContext {
　　String message();
　　Integer id();
　　MessageSource source();
　　}
　　interface EventListener {
　　// Awesome!
　　void message(MessageContext context);
　　}
　　比起EventListner SPI你可以更容易演进MessageContext API，因为很少用户会实现它。
　　规则: 无论何时指定SPI时，考虑使用上下文/参数对象，而不是写带有固定参数的方法。
　　备注: 通过专用的MessageResult类型交换结果也是一个好主意，该类型可以使用建设者API构造它。这样将大大增加SPI进化的灵活性。
　　3. 避免返回匿名，本地或者内部类
　　Swing程序员通常只要按几下快捷键即可生成成百上千的匿名类。在多数情况下，只要遵循接口、不违反SPI子类型的生命周期(SPI subtype lifecycle)，这样做也无妨。 但是不要因为一个简单的原因——它们会保存对外部类的引用，频繁的使用匿名、局部或者内部类。因为无论它们走到哪，外部类得跟到哪。例如，在局部类的域外操作不当的话，那么整个对象图会发生微妙的变化从而可能引起内存泄露。
　　规则：在编写匿名、局部或内部类前请三思能否将它转化为静态的或普通的类，从而避免方法将它们的对象返回到更外层的域中。
　　注意：使用双层花括号来初始化简单对象：
　　new HashMap<String， String>() {{
　　put("1"， "a");
　　put("2"， "b");
　　}}
　　这个方法利用了 JLS §8.6规范里描述的实例初始化方法(initializer)。表面上看起来不错，但实际上不提倡这种做法。因为要是使用完全独立的HashMap对象，那么实例不会一直保存着外部对象的引用。此外，这也会让类加载器管理更多的类。
　　4. 现在开始编写SAM！
　　Java8的脚步近了。伴随着Java8带来了lambda表达式，无论你是否喜欢。尽管你的API用户可能会喜欢，但是你好确保他们可以尽可能经常的使用。因此除非你的API接收简单的“标量”类型，比如int、long、String 、Date，否则让你的API尽可能经常的接收SAM。
　　什么是SAM？SAM是单一抽象方法[类型]。也称为函数接口，不久会被注释为@FunctionalInterface。这与规则2很配，EventListener实际上是一个SAM。好的SAM只有一个参数，因为这将会进一步简化lambda表达式的编写。设想编写
　　listeners.add(c -> System.out.println(c.message()));
　　来替代
　　listeners.add(new EventListener() {
　　@Override
　　public void message(MessageContext c) {
　　System.out.println(c.message()));
　　}
　　});
　　设想以JOOX的方式来处理XML。JOOX包含很多的SAM：
　　$(document)
　　// Find elements with an ID
　　.find(c -> $(c).id() != null)
　　// Find their child elements
　　.children(c -> $(c).tag().equals("order"))
　　// Print all matches
　　.each(c -> System.out.println($(c)))
　　规则：对你的API用户好一点儿，从现在开始编写SAM/函数接口。
　　备注：有许多关于Java8 lambda表达式和改善的Collections API的有趣的博客：
　　http://blog.informatech.cr/2013/04/10/java-optional-objects/
　　http://blog.informatech.cr/2013/03/25/java-streams-api-preview/
　　http://blog.informatech.cr/2013/03/24/java-streams-preview-vs-net-linq/
　　http://blog.informatech.cr/2013/03/11/java-infinite-streams/
　　5.避免让方法返回null
　　我曾写过1、2篇关于java NULLs的文章，也讲解过Java8中引入新的Optional类。从学术或实用的角度来看，这些话题还是比较有趣的。
　　尽管现阶段Null和NullPointerException依然是Java的硬伤，但是你仍可以设计出不会出现任何问题的API。在设计API时，应当尽可能的避免让方法返回null，因为你的用户可能会链式调用方法：
　　initialise(someArgument).calculate(data).dispatch();
　　从上面代码中可看出，任何一个方法都不应返回null。实际上，在通常情况下使用null会被认为相当的异类。像 jQuery或 jOOX这样的库在可迭代的对象上已完全的摒弃了null。
　　Null通常用在延迟初始化中。在许多情况下，在不严重影响性能的条件下，延迟初始化也应该被避免。实际上，如果涉及的数据结构过于庞大，那么要慎用延迟初始化。
　　规则：无论何时方法都应避免返回null。null仅用来表示“未初始化”或“不存在”的语义。