这是一个比Josh Bloch的Effective Java规则更精妙的10条Java编码实践的列表。和Josh Bloch的列表容易学习并且关注日常情况相比，这个列表将包含涉及API/SPI设计中不常见的情况，可能有很大影响。 我在编写和维护jOOQ(Java中内部DSL建模的SQL)时遇到过这些。作为一个内部DSL，jOOQ最大限度的挑战了Java的编译器和泛型，把泛型，可变参数和重载结合在一起，Josh Bloch可能不会推荐的这种太宽泛的API。 1 牢记C 的析构函数 记得C 的析构函数？不记得了？那么你真的很幸运，因为你不必去调试那些由于对象删除后分配的内存没有被释放而导致内存泄露的代码。感谢Sun/Oracle实现的垃圾回收机制吧！ 尽管如此，析构函数仍提供了一个有趣的特征。它理解逆分配顺序释放内存。记住在Java中也是这样的，当你操作类析构函数语法： 使用JUnit的@Before和@After注释 分配，释放JDBC资源 调用super方法 还有其他各种用例。这里有一个具体的例子，说明如何实现一些事件侦听器的SPI：
2 不要相信你早期的SPI演进判断 向客户提供SPI可以使他们轻松的向你的库/代码中注入自定义行为的方法。当心你的SPI演进判断可能会迷惑你，使你认为你(不)打算需要附加参数。当然，不应当过早增加功能。但一旦你发布了你的SPI，一旦你决定遵循语义版本控制，当你意识到在某种情况下你可能需要另外一个参数时，你会真的后悔在SPI中增加一个愚蠢的单参数的方法:
如果你也需要消息ID和消息源，怎么办？API演进将会阻止你向上面的类型添加参数。当然，有了Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策：
注意，不幸的是，defender方法不能使用final修饰符。 但是比起使用许多方法污染你的SPI，使用上下文对象(或者参数对象)会好很多。
比起EventListner SPI你可以更容易演进MessageContext API，因为很少用户会实现它。 规则: 无论何时指定SPI时，考虑使用上下文/参数对象，而不是写带有固定参数的方法。 备注: 通过专用的MessageResult类型交换结果也是一个好主意，该类型可以使用建设者API构造它。这样将大大增加SPI进化的灵活性。 3 避免返回匿名，本地或者内部类 Swing程序员通常只要按几下快捷键即可生成成百上千的匿名类。在多数情况下，只要遵循接口、不违反SPI子类型的生命周期(SPI subtype lifecycle)，这样做也无妨。 但是不要因为一个简单的原因它们会保存对外部类的引用，就频繁的使用匿名、局部或者内部类。因为无论它们走到哪，外部类就得跟到哪。例如，在局部类的域外操作不当的话，那么整个对象图就会发生微妙的变化从而可能引起内存泄露。 注意：使用双层花括号来初始化简单对象：
这个方法利用了 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表达式的编写。设想编写
来替代
设想以JOOX的方式来处理XML。JOOX就包含很多的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，因为你的用户可能会链式调用方法：
从上面代码中可看出，任何一个方法都不应返回null。实际上，在通常情况下使用null会被认为相当的异类。像jQuery或jOOX这样的库在可迭代的对象上已完全的摒弃了null。 Null通常用在延迟初始化中。在许多情况下，在不严重影响性能的条件下，延迟初始化也应该被避免。实际上，如果涉及的数据结构过于庞大，那么就要慎用延迟初始化。 6 设计API时永远不要返回空数组或List 尽管在一些情况下方法返回值为null是可以的，但是绝不要返回空数组或空集合！请看 java.io.File.list()方法，它是这样设计的： 此方法会返回一个指定目录下所有文件或目录的字符串数组。如果目录为空(empty)那么返回的数组也为空(empty)。如果指定的路径不存在或发生I/O错误，则返回null。 因此，这个方法通常要这样使用：
大家觉得null检查有必要吗？大多数I/O操作会产生IOExceptions，但这个方法却只返回了null。Null是无法存放I/O错误信息的。 因此这样的设计，有以下3方面的不足： Null无助于发现错误 Null无法表明I/O错误是由File实例所对应的路径不正确引起的 每个人都可能会忘记判断null情况 以集合的思维来看待问题的话，那么空的(empty)的数组或集合就是对“不存在”的最佳实现。返回空(null)数组或集合几乎是无任何实际意义的，除非用于延迟初始化。 7 避免状态，使用函数 HTTP的好处是无状态。所有相关的状态在每次请求和响应中转移。这是REST命名的本质：含状态传输(Representational state transfer)。在Java中这样做也很赞。当方法接收状态参数对象的时候从规则2的角度想想这件事。如果状态通过这种对象传输，而不是从外边操作状态，那么事情将会更简单。以JDBC为例。下述例子从一个存储的程序中读取一个光标。
这使得JDBC API如此的古怪。每个对象都是有状态的，难以操作。 具体的说，有两个主要的问题： 在多线程环境很难正确的处理有状态的API 很难让有状态的资源全局可用，因为状态没有被描述 8 短路式 equals() 这是一个比较容易操作的方法。在比较复杂的对象系统中，你可以获得显著的性能提升，只要你在所有对象的equals()方法中首先进行相等判断:
注意，其它短路式检查可能涉及到null值检查，所以也应当加进去:
|
注册
登录
