我使用 Java 8 编码已经有些年头，既用于新的应用程序，也用来迁移现有的应用，感觉是时候写一些我发现的非常有用的 “最佳实践”。我个人并不喜欢“最佳实践” 这个说法，因为它意味着 “一刀切” 的解决方案，而编码不可能是这样的工作方式——我们需要亲自去发现什么样的解决方案才是有效的。但是我发现了一些 Java 8 代码中可以帮助我们的一些选择，让我们一起来看看吧。

1.Optional

Optional 是一个严重被低估的功能，并且有潜力删除很多困扰我们的 NullPointerExceptions。这在代码边界中(要么是正在使用的 API，要么是正在暴露的 API)特别有用，因为它允许你和你的调用代码来推理所期待的东西。

然而，不加思考和设计就应用 Optional 可能会导致影响大量的类，并可能导致可读性更差。下面是一些关于如何高效使用 Optional 的技巧。

Optional 应该只用于返回类型

…… 不是参数，也不是字段。幸运的是，IntelliJ IDEA 的让你打开检查来查看是是否遵循这些建议。

Optional 值应在遇到它们的地方中处理。IntelliJ IDEA 的建议会防止代码 Optional 泄漏，所以请记得在你发现 Optional 的地方处理它，迅速采取行动。

不应该简单调用 get()

Optional 的功能是表达这个值可能是空的，并让你应对这种情况。因此，在对它做任何事情之前一定要检查是否有一个值。只是简单得调用 get() 而不先检查 isPresent() 在某些时候可能会导致空指针。幸运的是，IntelliJ IDEA 也有检查可以提醒你这一点。

可能有更优雅的方式

结合了 get() 的 isPresent() 当然会很赞…

…… 但也有更优雅的解决方案。你可以使用 orElse 在万一是空值的情况下给一个替代方案。

…… 或者你可以使用 orElseGet 说明在值为空的情况下调用哪个方法。这似乎与上面的例子相同，但 supplier 方法将只在需要的时候调用，因此，如果这是一种昂贵的方法，那么使用 lambda 会有更佳性能。

2. 使用 Lambda 表达式

Lambda 表达式是 Java 8 的主要特点之一。即使你还没有使用 Java 8，你现在可能已经对它们有了基本的了解。它们是用 Java 编程的一种新的方式，并且什么是 “最佳实践” 还不明显。下面是我喜欢遵循的一些指引。

保持简短

函数式程序员与较长的 lambda 表达式相处会更愉快，但那些淫浸于 Java 多年的人会发现保持 lambda 表达式为区区几行代码更容易。你甚至可能更愿意将其限制到一行代码，并且你可以轻松重构较长的表达式为一个方法。

这些甚至可能会成为方法引用。方法引用一开始会觉得有点陌生，但实际上坚持方法引用是有价值的，因为它们在某些情况下有助于可读性，后面我会讨论到这一点。

明确

类型信息缺少 lambda 表达式，所以你可能会觉得包含类型信息用于参数会很有用。

正如你所见，这回变得相当笨拙。所以我更喜欢给参数取一个有用的名字。当然，不管你有没有这么做，IntelliJ IDEA 可以让你看到参数得类型信息。

甚至是 lambda 所代表的函数式接口：

3. 针对 Lambda 表达式设计

我认为 lambda 表达式有点像泛型——和泛型一起，我们经常使用它们(例如，添加类型信息到 List<>)，但最好我们可以设计一种方法或一个具有泛型类型(例如 Person< T>)的类。同样的，当使用类似于 Streams API 的东西时，我们会传递 lambda 表达式，但更好的是创造一个需要 lambda 参数的方法。

但是，如果你发现自己处于这类情况下，下面有一些超棒的技巧。

IntelliJ IDEA 可以帮你引进函数式参数

这让你可以在有人将传递一个 lambda 而非 Object 的地方创建一个参数。此功能的好处是，它表明，现有函数式接口匹配规格说明。

这会导致…

使用现有的函数式接口

随着开发人员越来越熟悉 Java 8 代码，我们就能知道当使用如 Supplier 和 Consumer 的接口时，会发生什么，以及创建一个本地的 ErrorMessageCreator(举个例子)可能会造成混乱，而且浪费。看看这个函数包了解一下哪些已经是可用的。

添加 @FunctionalInterface 到函数式接口

如果你确实需要创建自己的函数式接口，那么就这样用此注释标记。这似乎没有太大的作用，但 IntelliJ IDEA 会告诉你，在你的接口不能匹配用于函数式接口的异常的时候。当你没有指定要覆盖的方法时，它会标志：

当你指定了太多方法的时候，它会标志：

并且如果你应用它到一个类而不是接口时，它会警告你：

lambda 表达式可用于带有一个单一抽象方法的任何接口，但它们不能用于符合相同标准的抽象类。似乎不合逻辑，但就是这样。

4.Stream

Stream API 是 Java 8 另一个大特点，并且我认为我们还真的不知道这对我们的编码方式会产生多大的改变。下面是我发现的一些有用的东西

排队点操作符

我个人更喜欢排队我的流操作。当然，你没有必要这样，当我发现这样做对我有帮助：

一目了然地看到我有哪些操作

调试更容易(虽然 IntelliJ IDEA 确实提供了对一行中的任意多个 lambda 表达式设置断点的能力，但是拆分到不同的行会变得更简单)

当我测试东西的时候注释操作

轻松插入 peek() 用于调试或测试

此外，在我看来，它更整洁。如果我们按照这个模式，在减少代码行数方面我们并没有增加很多。

你可能需要调整格式设置以排列点操作符。

使用方法引用

是的，确实需要一段时间来适应这个奇怪的语法。但是，如果使用得当，它确实可以增加可读性。请看：

与(相对)新的 Objects 类上的辅助方法相比较：

后者的代码对于哪些值是要保存的更加明确。当 lambda 可以被折叠到方法参考的时候，IntelliJ IDEA 通常会让你知道。

当遍历一个集合时，在可行的情况下使用 Streams API

… 或者新的集合方法，如 forEach。IntelliJ IDEA 给你建议是：

一般使用 Streams API 比循环和 if 语句的组合更加明确。例如：

IntelliJ IDEA 建议这可重构为：

我所做的性能测试表明这种重构令人惊讶——并不总是可预测性能是保持不变，改善还是变得更糟。与往常一样，如果性能在应用程序中是关键，那么在交付一种风格到另一种之前衡量它。

遍历数组时使用循环

但是，使用 Java 8 并不一定意味着你必须到处使用流和新的集合方法。IntelliJ IDEA 会建议转换成流，但是，这并不意味着你必须回答 “yes”(记得检查是可以抑制或关闭的)。

特别是，遍历原始类型的小型数组几乎肯定会用，以获得更好的性能循环，很可能(至少对于 Java 开发人员是新的流)更具可读性。

与任何技巧一样，规则并不是一成不变的，但你应该决定是尽可能地使用 Streams API，还是依然对一些操作使用循环。总之，要一致。

最后

每天都在发现新的东西，并且有时候我的偏好会发生变化——例如，方法引用，我曾经深恶痛绝并且避免在我的代码中使用。现在我很想听听你的秘诀！