在Java8中使用可选的需要注意哪些问题

今天就跟大家聊聊有关在Java8中使用可选的需要注意哪些问题,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

<强>前言

Java 8引入的可选类型,基本是把它当作零值优雅的处理方式。其实也不完全如此,可选在语义上更能体现有还是没有值,所以它不是设计来作为零的替代品,如果方法返回零值表达了二义性,没有结果或是执行中出现异常。

在Oracle 做,Java语言工作的,Brian Goetz在堆栈溢出回复应该Java 8 getter返回可选的类型?中讲述了引入,可选的主要动机。

我们的意图是提供一个有限的图书馆机制方法返回类型,需要一个清晰的方式来表示“没有结果”,并使用零就是这样极有可能导致错误。

说的是,可选的提供了一个有限的机制让类库方法返回值清晰的表达有与没有值,避免很多时候零造成的错误。并非有了,可选就要完全杜绝NullPointerException。

在Java 8之前一个实践是方法返回集合或数组时,应返回空集合或数组表示没有元素;而对于返回对象,只能用零来表示不存在,现在可以用,可选来表示这个意义。

自Java8于,2014-03-18发布后已5年有余,这里就列举几个我们在项目实践中使用可选常见的几个用法。

<强>可选类型作为字段或方法参数

这儿把Optional 类型用为字段(类或实例变量)和方法参数放在一起来讲,是因为假如我们使用IntelliJ IDEA来写Java 8代码,想法对于,可选作为字段和方法参数会给出同样的代码建议:

报告任何使用java.util.Optional,java.util。OptionalDouble java.util。OptionalInt java.util。OptionalLong或com.google.common.base.Optional字段或参数的类型。可选的设计提供了一种有限的机制库方法返回类型,需要一个清晰的方式来表示“没有result"。使用一个字段java.util型。可选的也有问题,如果需要可序列化的类,java.util。可选的不是。

不建议用任何的可选类型作为字段或参数,可选的设计为有限的机制让类库方法返回值清晰的表达“没有值“。可选的是不可被序列化的,如果类是可序列化的就会出问题。

上面其实重复了Java 8引入,可选的意图,我们还有必要继续深入理解一下为什么不该用,可选作为字段或方法参数。

当我们选择选类型而非内部包装的类型后,应该是假定了该可选类型不为null,否则我们在使用可选字段或方法参数时就变得复杂了,需要进行两番检查。

public  class  User  { 　　,private  String  firstName; 　　,private  Optional middleName =, Optional.empty (); 　　,private  String 姓; 　　, 　　,public  void  setMiddleName (Optional

由于middleName的setter方法,我们可能造成middleName变为零值,所以在构建fullName时必须两重检查。

并且在调用<代码> setMiddleName(…) 方法时也有些累赘了

user.setMiddleName (Optional.empty ()); 　　user.setMiddleName (Optional.of (“abc"));

而如果字段类型非可选类型,而传入的方法参数为可选类型,要进行赋值的话

, private  String  middleName; 　　, 　　,public  void  updateMiddleName (Optional

前面两段代码如果应用<代码> Optional.ofNullable(…)> 如果(middleName !=null)>

对于本例直接用字符串类型的middleName 作为字段或方法参数就行,null值可以表达没有middleName。如果不允许null值,middleName,显式的进行入口参数检查而拒绝该输入——抛出异常。

<>强利用可选过度检查方法参数

这一可选的用法与之前的可能为null值的方法参数,不分清红皂白就用,如果……其他检查,总有一种不安全感,步步惊心,结果可能事与愿违。

在Java8中使用可选的需要注意哪些问题