使用Optional.ofNullable替换三元运算符是否是一种良好的做法?

每当我想到为特定目的使用可选API时,我总是提醒自己它的目的是什么,以及为什么它被引入JDK,也就是说。

中的可选选项旨在为库方法提供有限的机制 在这里使用null极有可能导致错误-Stuart Marks

Optional主要关注可能有返回值或可能没有返回值的返回类型。

我会让事情简单化,而是做:

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

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

这避免了重复 sayHi() Optional . :-)

这个用法是 Optional.ofNullable

Conceptually ,这是个坏习惯。基本思想是表示没有返回值,而不是包装可能存在的所有内容 null

或者只是额外的冗长编码?

在我看来,让你的代码更时尚的尝试失败了看,我们用的是全新的 Optional 来自Java8!)

我更喜欢可读性和清晰性,而不是简洁性。

Optinal 用法并不清晰,但会引发问题:

为什么要包装变量?
可选的 ?

它也不简洁:你的第二行甚至更短。

为了避免这个问题,您实际上可以创建一个额外的变量,但这会增加三元选项的冗长性。

您没有创建额外的变量。单线版本可以是:

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

不过,你的两行建议绝对不错:

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

如果你允许的话 Optional 在您的工作流程中,您应该考虑修改 sayHi() 方法,使其返回 Optional<String> 这将使结果更加优雅:

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

可选的

关于 可选的

另外,如果你最感兴趣的是 String 然后要意识到 Objects.toString(Object, String)

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

这比手工编写代码更整洁、更优雅。

Optional<String> 并让调用方处理缺少的值。

可选的,作为一元类型,可以利用更多,而不仅仅是获得一个alt值。

在你的另一端 操作人员

简言之:避免 Optional 类型。 主要论点 可选的 关于返回类型,“客户很容易忘记处理返回值为null的可能性。 可选的

可选的 Nothing is better than the Optional type .