这是10个非常好的实践的列表，比你平时在Josh Bloch的《effective java》中看到的规则更加精妙。和Josh Bloch列出的非常容易学习的、和日常情况息息相关的实践相比，这个列表中提到了一些关于设计API/SPI的实践，虽然不常见，但是存在很大的效率问题。
我在编写和维护jOOQ(一种内部DSL，在java中将SQL模块化)时，碰到了这些问题。作为内部DSL，jOOQ最大限度的挑战了java编译器和泛型，把泛型，变量和重载结合到了一起。这种太宽泛的API是Josh Bloch相当不推荐的。
让我来和你分享这10个java编码中微妙的非常好的实践：
1.牢记C++的析构函数
还记得C++中的析构函数吗?不记得了?或许你真的很幸运，因为你再也不必为删除对象后，没有及时释放内存而造成内存泄露进行调试了。我们真的应该感谢Sun和Oracle实现垃圾回收机制。
尽管如此，对于我们来说，析构函数仍然有一个很有趣的特点。它常常会让我们对以和分配内存相反的顺序释放内存的工作模式感到容易理解。同样，在JAVA代码中，当你处理如下类析构函数语法的时候，也要把这个特性牢记在心：
• 当使用@Before和@After但与注解时;
• 当分配和释放JDBC资源时;
• 当调用父类的方法时。
也有其他不同的使用案例。这有一个显示如何实现事件监听的实例：
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);
}
法则：无论何时，当你使用before/after, allocate/free, take/return语法实现逻辑时，仔细想想是否需要反序的使用after/free/return操作。
2. 不要相信你早期的SPI演进判断
为使用者提供SPI可以很容易让他们注入自定义行为到你的库/代码。当心你的SPI演进判断可能会迷惑你，让你认为(不)需要附加的参数。当然，不应该过早的添加功能。但是一旦你发布了SPI，一旦你决定遵循语义版本，当你发现你可能在某些情况下需要另外一个参数时，你将真的后悔为SPI添加了一个愚蠢的单参数方法：
// Bad
void message(String message);
}
如果你也需要消息ID和消息源，怎么办?对于上面的类型，API演进将会阻碍你添加参数。当然，有了Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策：
// Bad
default void message(String message) {
message(message, null, null);
}
// Better?
void message(
String message,
Integer id,
MessageSource source
);
}
注意很不幸defender方法不能为final。
但是比起用数十个方法污染你的SPI，使用一个上下文对象(或参数对象)好很多。
String message();
Integer id();
MessageSource source();
}
interface EventListener {
// Awesome!
void message(MessageContext context);
}
比起EventListner SPI你可以更容易演进MessageContext API，因为很少用户会实现它。
规则: 无论何时你指定SPI的时候， 考虑使用上下文/参数对象，而不要编写固定参数数量的方法。
备注: 使用特定的MessageResult类型传递结果也是一个好的想法，该类型可以通过构造器API构建。这将会为你的SPI提供更多的SPI演进灵活性。
3.避免使用匿名，局部或内部类
Swing程序员通常只要按几下快捷键即可生成成百上千的匿名类。在多数情况下，只要遵循接口、不违法SPI子类型的生命周期(SPI subtype lifecycle)，这样做也无妨。
但是不要因为一个简单的原因——它们会保存对外部类的引用，就频繁的使用匿名、局部或者内部类。因为无论它们走到哪，外部类就得跟到哪。例如，在局部类的域外操作不当的话，那么整个对象图就会发生微妙的变化从而可能引起内存泄露。
规则：在编写匿名、局部或内部类前请三思能否将它转化为静态的或普通的优异类，从而避免方法将它们的对象返回到更外层的域中。
注意：使用双层花括号来初始化简单对象：
put("1", "a");
put("2", "b");
}}
这个方法利用了 JLS §8.6规范里描述的实例初始化方法(initializer)。表面上看起来不错，但实际上不提倡这种做法。因为要是使用完全独立的HashMap对象，那么实例就不会一直保存着外部对象的引用。此外，这也会让类加载器管理更多的类。
