这是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资源时 当调用父类的方法时
也有其他不同的使用案例。这有一个显示如何实现事件监听的实例:
02 | public void beforeEvent(EventContext e) { |
08 | public void afterEvent(EventContext e) { |
另外一个哲学家用餐的问题,显示了这有多么的重要。

关于哲学家用餐的问题,请查看链接:http://adit.io/posts/2013-05-11-The-Dining-Philos ophers-Problem-With-Ron-Swanson.html
法则:无论何时,当你使用before/after, allocate/free, take/return语法实现逻辑时,仔细想想是 否需要反序的使用after/free/return操作。
2. 不要相信你早期的SPI演进判断为使用者提供SPI可以很容易让他们注入自定义行为到你的库/代码。当心你的SPI演进判断可能会迷惑你, 让你认为(不)需要附加的参数。当然,不应该过早的添加功能。但是一旦你发布了SPI,一旦你决定遵循 语义版本,当你发现你可能在某些情况下需要另外一个参数时,你将真的后悔为SPI添加了一个愚蠢的单 参数方法: 1 | interface EventListener { |
3 | void message(String message); |
如果你也需要消息ID和消息源,怎么办?对于上面的类型,API演进将会阻碍你添加参数。当然,有了 Java8,你可以添加一个defender方法,“防御”你早期糟糕的设计决策: 01 | interface EventListener { |
03 | default void message(String message) { |
04 | message(message, null , null ); |
注意很不幸defender方法不能为final。 但是比起用数十个方法污染你的SPI,使用一个上下文对象(或参数对象)好很多。
01 | interface MessageContext { |
04 | MessageSource source(); |
07 | interface EventListener { |
09 | void message(MessageContext context); |
比起EventListner SPI你可以更容易演进MessageContext API,因为很少用户会实现它。 规则: 无论何时你指定SPI的时候, 考虑使用上下文/参数对象,而不要编写固定参数数量的方法。 备注: 使用特定的MessageResult类型传递结果也是一个好的想法,该类型可以通过构造器API构建。 这将会为你的SPI提供更多的SPI演进灵活性。
|