Question

考虑此表达式的用法：

String hi = Optional.ofNullable(sayHi()).orElse("-");

实际上与该三元表达式相对应：

String hi = sayHi() != null ? sayHi() : "-";

将Optional.ofNullable与方法结合使用是一种好的做法吗？还是只是多余的编码？

我认识到Optional.ofNullable实际上创建了一个变量，并且避免了两次调用sayHi()方法。为避免此问题，您实际上可以创建一个额外的变量，但这会增加三元选项的详细程度：

String hi = sayHi();
hi = hi != null ? hi : "-";

另一方面，Optional.ofNullable在hi不是null的情况下创建了额外的Optional对象。因此，肯定会有更多开销。

因此，使用这种类型的结构来代替三元构造函数似乎有一些利弊。

顺便说一句：这是Optional.ofNullable的Java 8实现：

public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
}

Answer 1

每当我想到出于特定目的使用Optional API时，我总会提醒自己该打算做什么以及为什么将其引入JDK和

可选，旨在为库方法提供有限的机制需要明确表示“无结果”的返回类型，以及在其中使用null的情况极有可能导致错误-Stuart Marks

Optional主要集中在可能具有或没有返回值的返回类型上。

像您在本示例中那样过度使用此构造只会导致额外的内存分配和GC开销。

我会简单一些，而是去做：

String hi = sayHi();
if(hi == null) hi = “-“;
...

Answer 2

在JDK 9或更高版本中，使用此命令：

String hi = Objects.requireNonNullElse(sayHi(), "-");

这避免了在使用三元运算符的情况下必须重复sayHi()或将其值分配给在三元内部重用的局部变量的情况。这可能是一个很小的改进。它还回避了是否使用Optional的问题。：-）

Answer 3

将select * from record where extract (year from recorddate) = 2018与方法结合使用是一种好习惯吗？

Conceptually，这是一个不好的做法。基本思想是表示没有返回值，而不是包装可能为Optional.ofNullable的所有内容。我强烈反对这种用法。

还是只是多余的编码？

在我看来，这是使您的代码更加时尚的失败尝试。（“看，我们正在使用Java 8中的全新null！”）

与简洁相比，我更喜欢可读性和清晰度。

这种Optional用法并不清楚，但引起了疑问：

为什么要包装变量？
您将如何处理此Optinal？
会在下面使用/返回吗？

它也不简洁：第二行更短。

为避免此问题，您实际上可以创建一个额外的变量，但这会增加三元选项的详细程度。

您没有创建额外的变量。单行版本可能是：

Optional

不过，您的两行建议绝对可以：

String hi = (hi = sayHi()) != null ? hi : "-";

Answer 4

如果您要允许Optional进入工作流，则应考虑修改sayHi()方法，使其返回Optional<String>，这将使结果更加美观：

hi = sayHi().orElse("-");

如果您不想在工作流程中引入Optional（因为它确实创建了一个包含可选值的附加对象），那么最好不要使用简单的null检查和三元运算符。 / p>

关于Optional的性能成本（例如增加的垃圾回收），您需要分析应用程序并确定这是否是真正的问题。

另外，如果您对String最感兴趣，那么请注意Objects.toString(Object, String)方法，如果对象为null，该方法将返回默认值：

hi = Objects.toString(hi, "-");

与手动编写代码相比，这更加整齐且优雅。

Answer 5

我认为这主要是个人喜好问题。

从我的角度来看，只返回一个Optional<String>并让调用者处理丢失的值会更有意义。

可选的单峰类型，可以利用它来获取更多值，而不仅仅是获得alt值。

另一方面，您的 operator 似乎很简洁，如果使用得当的话，可能会很实用。

我认为这里的性能不是大问题。

Answer 6

简而言之：避免使用Optional类型。返回类型的Optional的主要论据是：“客户太容易忘记处理返回空值的可能性。Optional丑陋而笨拙，因此客户的可能性较小忘记处理返回值为空的可能性。在其他任何地方，程序员都应继续使用常规引用，该引用可能为null。”

我讨论了使用Java的Optional类型：Nothing is better than the Optional type的优缺点。