Java 8 最佳技巧

翻译文章

在过去的几年中，我一直使用Java 8 进行了很多的编码工作，用于开发新应用和迁移遗留应用，我觉得是时候写一些有用的”最佳实践”。我个人不喜欢”最佳实践”这个术语，因为它意味着“一刀切”的解决方案，当然编码工作是不会这样的–这是因为我们开发人员会想出适合我们的方案。但我发现我对Java8特别的喜欢，它让我的生活更轻松一点，所以我想就此话题展开讨论。

`Optional`

Optional 是一个被严重低估的功能, 它消除了很多困扰着我们的 NullPointerExceptions。它在代码边界（包括你调用和提供 API）处理上特别有用，因为它允许你和你调用的代码说明程序运行的期望结果。

然而，如果没有必要的思考和设计，那么就会导致一个小变化而影响大量的类，也会导致可读性变差。这里有一些关于如何高效使用Optional的提示。

`Optional` 应该只用于返回类型

…不能是参数和属性. 阅读这个博客了解怎样使用 Optional。幸运的是, IntelliJ IDEA 在打开 inspection 功能的情况下会检查你是否遵循了这些建议。

可选值应该在使用的地方进行处理. IntelliJ IDEA的建议可以防止你不恰当的使用Optional, 所以你应该立即处理你发现的不恰当使用Optional。(根据自己的理解翻译)

你不应该简单的调用 `get()`

Optinal的目的是为了表示此值有可能为空，且让你有能力来应付这种情况。因此，在使用值之前进行检查是非常重要的。在某些情况下简单的调用get()而没有先使用isPresent()进行检查是一样会导致空指针问题。幸运的是，IntelliJ IDEA 任然会检查出这个问题并警告你。

有可能是一个更优雅的方式

isPresent() 与 get() 结合 使用的技巧 …

…但还有更优雅的解决方案。你可以使用 orElse方法来使得当它为null时给出一个代替的值。

…或者使用 orElseGet方法来处理上述相同情况。这个例子和上面的看起来好像一样，但本例是可以调用 supplier 接口的 实现 ,，因此如果它是一个高开销的方法，可以使用 lambda 表达式来获得更好的性能。

使用Lambda表达式

Lambda 表达式是 Java 8 的卖点之一.。即使你还没有使用过Java 8，到目前你也可能有一些基本的了解。但在Java编程中还是一种新的方式，它也不是明显的”最佳实践” 。这里有一些我遵循的指南。

保持简短

函数式程序员更愿意使用较长的lambda 表达式，但我们这些仅仅使用Java很多年的程序员来说更容易保持lambda 表达式的短小。你甚至更喜欢把它们限制在一行，更容易把较长的表达式重构到一个方法中。

把它们变成一个方法引用，方法引用看起来有一点陌生，但却值得这样做，因为在某些情况有助于提高可读性，后面我再谈可读性。

明确的

(作者应该想要表达的是: 参数命名规范，要有意义；有更好的翻译请修正)

lambda 表达式中类型信息已经丢失了，因此你会发现包含类型信息的参数会更有用。

如你所见，这样会比较麻烦。因此我更喜欢给参数一个更有意义的命名。当然，你做与否， IntelliJ IDEA 都会让你看到参数的类型信息。

即使是在函数式接口的lambda 表达式中:

针对 `Lambda` 表达式进行设计

我认为lambda表达式有点像泛型 – 泛型,我们经常使用它们 (例如, 给 List<> 添加类型信息 )，但不常见的是我们把一个方法或类泛型化 (如: Person<T> )。同样的, 它就像我们使用通过lambdas包装的 Streams API，但对我们来说更罕见的是创建一个需要 lambda 表达式参数的方法。

`IntelliJ IDEA` 可以帮助你引入一个函数化的参数

这里让你可以使用 Lambda 表达式而非对象来创建一个参数。这个功能的好处在于其建议使用一个已有的函数接口来匹配这个规范。

这个将引导我们

使用已有的函数接口

当开发者越来越熟悉 Java 8 代码时，我们会知道使用例如 Supplier 和 Consumer 这样的接口会发生什么，但是单独再创建一个 ErrorMessageCreator 会让我们很诧异并且很浪费时间。你可以翻阅 function package 来查看系统本身已经给我们准备了什么。