龙目岛可选

Dhr*_*aya 36 java optional lombok

我有一个类Address看起来像这样:

@Value
class Address {

   @NotNull String userId;
   @NotNull String line1;
   String line2;

   private Address(Builder b) {
      // copy everything from builder
   }

   // override getter for line2 so that it returns Optional<String>
   public Optional<String> getLine2() {
      return Optional.ofNullable(this.line2);
   }

   // and a Builder
   public static class Builder {
     // builder methods
   }
}
Run Code Online (Sandbox Code Playgroud)

在这里我被迫写Builder了一个Getter因为,如果我想在使用Lombok时返回一个Optional,我必须声明line2Optional<String>.这将生成一个接受的构建器方法Optional<String>!

还有其他方法可以使用lombok Optional吗?

Roe*_*ker 14

答案是否定的,而且可能永远不会.

你可能做错了:-) Optional不是替代,null也不是预防的奇特方式NullPointerException.这表明这个问题是无法回答的,例如:一个空列表的平均年龄是多少.

Optional应该永远不会传递s,但是尽快通过调用代码取消装箱.

另请参见https://www.voxxed.com/blog/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/

由于这些场景只是少数几个,而Lombok喜欢让程序员编写更好的代码,我不希望在Lombok中会有它的支持.

披露:我是Lombok开发人员.

  • "可选不是null的替代,也不是防止NullPointerException的奇特方式"<这正是Java架构师所说的,不会因为他们已经在Java中引入了一个功能(伪)monad而吓跑命令式程序员.可选_is_一个允许无空代码的结构,Java可以用函数方式编写.看看Javaslang吧. (26认同)
  • 我真的很感谢你回答这个问题!谢谢!我知道这种不使用`Optional`替代`null`的哲学.如果在吸气剂中使用它会过度使用`Optional`.但是Google Guava的开发人员还有另一种更方便的哲学,它允许你使用Optional替换null [Guava的可选](http://docs.guava-libraries.googlecode.com/git/javadoc/com/google /common/base/Optional.html)所以,我个人认为`lombok` shld保持中立并提供对autoOptional的支持,并留下是否对程序员使用它 (21认同)
  • 我的意思是生成的getter看起来像代码样本[这里](http://blog.codefx.org/java/stephen-colebourne-optional-a-strict-approach/)并且会通过类似`@的东西添加Getter(可选= true)`. (13认同)
  • 对于`@Getter(可选=真)来说绝对是一个很大的好处,这会让我很开心. (7认同)
  • 正如来自者评论所建议的那样,越来越多地处理函数式编程使得支持 Getters 的可选性变得越来越有效。我认为这种宗教思想会伤害龙目岛。 (5认同)
  • 遗憾的是,这不被支持,只是因为 Lombok 开发人员认为“Java 中的可选是一个坏主意”——可以在 Lombok 代码中随意避免它,但 Lombok 用户应该有选择。 (4认同)
  • Optional 是 null 的替代品,它的来源实际上完全以 null 检查为中心。您可以使用它以声明性和类型安全的方式告诉调用者“嘿,这里有一个可能为空的值,请处理它”。它还减少了大量的样板文件(如果使用正确,还可以消除 NPE)。但是,您当然可以滥用可选,但这取决于开发人员。我们使用 lombok 来减少样板文件,而不是让我们的实践变得更好。PS 仅仅因为您到处使用一些 lambda 表达式来处理空值,并不意味着您突然切换到函数式范例。 (4认同)
  • 我只能说哈哈。可选是一种很好的机制,可以强制您处理可能缺少值的情况,并帮助您编写更好的可读代码。恕我直言,狂热的“可选是邪恶”的思维方式是老派思想的命令式程序员的陈述 (4认同)
  • @RoelSpilker为什么不使用@Getter(optional = true)在可为空的字段的getter中生成“ Optional”返回类型?即那些没有标有“ @NonNull”的标签? (3认同)
  • “永远不应该传递可选项,而是应尽快由调用代码取消装箱。” - 为什么? (3认同)
  • @RoelSpilker“*我们总是可以添加功能,但我们确实尝试首先关注最重要的功能。我们认为这不是其中之一*”要求此操作的 GitHub 问题现在是请求最多的开放问题(不包括SuperBuilder 的复制品,应该关闭)所以,恕我直言,Lombok 的用户不同意你的观点。 (3认同)
  • 嘿@RoelSpilker!由于Lombok已经在某种程度上存在固执(例如`@NonNull`将在生成的构造函数中添加空检查),我相信能够使用返回`Optional`的getter是一个非常有趣的功能.我能以某种方式捐款吗? (2认同)
  • “这是为了表明这个问题是无法回答的,比如:一个空名单的人的平均年龄是多少。” 你有这个想法的来源吗?更常见的应用是:在集合中查找返回可选的元素(是否存在)并使用 map() 函数对其进行操作。javadoc 将 Optional 指定为:“可能包含也可能不包含非空值的容器对象。”,我完全将其读作“空值的替代品”。 (2认同)
  • 我认为关于不传递 Optionals 的论点是基于这样一个事实,即 Optional 本身它是不可设置的,并且它是故意这样设计的,如果我没有错的话,可以避免以这种方式使用它。这就是为什么建议反对 Optional 类型的类成员的原因。但相反,我可以看到这样的用例,其中 getter 的返回可以将字段装箱为一个可选的,这就是为什么我也想要 Lombok 可选的 getter。PS vavr(一个提供函数式编程结构的优秀 Java 库)它是可序列化的选项! (2认同)
  • 最好标记为“选项永远不应被传递,但应尽快由调用代码拆箱”。答案中明确表达个人观点 (2认同)