10 个Java 编码中微妙最佳实践.docVIP

10 个Java 编码中微妙的最佳实践这是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资源时 　　当调用父类的方法时 　　也有其他不同的使用案例。这有一个显示如何实现事件监听的实例： ? 1 2 3 4 5 6 7 8 9 10 11 @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添加了一个愚蠢的单参数方法： ? 1 2 3 4 interface EventListener { // Bad void message(String message); } 如果你也需要消息ID和消息源，怎么办？对于上面的类型，API演进将会阻碍你添加参数。当然，有了Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策： ? 1 2 3 4 5 6 7 8 9 10 11 12 interface EventListener { // Bad default void message(String message) { message(message, null, null); } // Better? void message( String message, Integer id, MessageSource source ); } 　　注意很不幸defender方法不能为final。 　　但是比起用数十个方法污染你的SPI，使用一个上下文对象（或参数对象）好很多。 ? 1 2 3 4 5 6 7 8 9 10 interface MessageContext { String message(); Integer id(); MessageSource source(); } interface EventListener { // Awesome! void message(MessageContext context); } 　　比起EventListner SPI你可以更容易演进MessageContext API，因为很少用户会实现它。 　　规则: 无论何时你指定SPI的时候， 考虑使用上下文/参数对象，而不要编