为什么在Java 8+中使用Optional而不是传统的空指针检查？

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

#1 楼

样式2不足以使用Java 8来获得全部好处。您根本不需要if ... use。请参阅Oracle的示例。采纳他们的建议，我们会得到：

样式3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

或更长的代码段

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

#2 楼

如果将Optional用作可能仍返回null的较旧API之间的“兼容性”层，则在确定您拥有某些东西的最新阶段创建（非空）Optional可能会有所帮助。例如，您在哪里写道：

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

我会选择：

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

重点是您知道这里有一个非空的员工服务，因此您可以将其包装在带有Optional的Optional.of()中。然后，当您致电getEmployee()时，您可能会或可能不会雇用一名雇员。该雇员可能（或可能没有）ID。然后，如果您以ID结尾，则要打印它。

无需在此代码中显式检查任何null，状态等。

#3 楼

Optional为单个值，几乎没有附加值。如您所见，这只是用检查存在性来代替对null的检查。

拥有Collection这样的东西具有巨大的附加价值。引入的所有用于替换旧式低级循环的流方法都可以理解Optional的事情并对其进行正确的处理（不对其进行处理或最终返回另一个未设置的Optional）。如果您处理n个项目的频率比处​​理单个项目的频率高（所有现实程序中的99％都要处理），那么对可选内容的内置支持是一项巨大的进步。在理想情况下，您无需检查null或存在。

#4 楼

只要您像使用Optional的高级API一样使用isNotNull()，那么是的，仅检查null就不会发现任何区别。

您不应该将Optional用于

仅使用Optional来检查值是否存在错误代码：

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

应将Optional用于

避免使用不返回值，可以在使用null返回API方法时在必要时生成一个值：

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

或者，如果创建新Employee的成本太高：

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

另外，还请大家注意您的方法可能不会返回值（如果由于某种原因而无法返回上述默认值）：

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

最后，在其他答案中已经解释了所有类似流的方法，尽管这些并不是您真正决定使用Optional的方法，而是利用某人提供的Optional其他。

#5 楼

当开发人员需要检查函数是否返回值时，使用Optional的关键是要保持清楚。

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

#6 楼

您的主要错误是您仍在使用更多程序性术语进行思考。这并不意味着对您作为一个人的批评，仅是一种观察。用更多的功能性思维思考需要时间和实践，因此方法是现成的，看起来像是最明显的正确事物需要您的配合。您的第二个小错误是在方法内部创建Optional。 Optional旨在帮助记录某些内容可能会或可能不会返回值的情况。您可能什么也不会得到。当然，问题很快就会变成“为什么isPresent甚至到达那里？”

这里很多人想念的一件事是isPresent（）并不是人们编写的新代码产生的充分了解了有用的lambda的功能，以及谁喜欢它的功能。

它的确为我们带来了几（两）个好，好，富有魅力的好处？ />

简化了旧代码使用新功能的过渡。
简化了Optional的学习过程。

第一个很简单。

假设您有一个看起来像这样的API：

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

并且您有一个使用此类的旧类（填空） ：

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

可以肯定的例子。但是请允许我在这里。

Java 8现在已经启动，我们正努力加入。
所以我们要做的事情之一就是我们要用某种东西来替换旧界面。会返回Optional。
为什么？
因为其他人已经很亲切地提到过：
这使人们不必猜测某些内容是否可以为空
其他人已经指出了这一点。但是现在我们有一个问题。想象我们有（对不起，当我在一个无辜的方法上按下alt + F7时），在经过良好测试的旧代码中调用此方法的位置有46个，否则它将发挥出色的作用。现在您必须更新所有这些。

这就是isPresent发光的地方。

因为现在：
Snickers lastSnickers = snickersCounter.lastConsumedSnickers（）;
if（null == lastSnickers）{
抛出新的NoSuchSnickersException（）;
}
else {
Consumer.giveDiabetes（lastSnickers）;
}

变成：

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

这是一个简单的更改，您可以给新任初级人员：他可以做一些有用的事情，并且他将继续探索代码库在同一时间。双赢。毕竟，类似于这种模式的东西非常普遍。现在，您不必使用lambda或其他任何东西就可以重写代码。
（在这种情况下，这是微不足道的，但是我想起了一些示例，这些示例对于读者来说是很困难的练习。）

请注意，这意味着您执行此操作本质上是一种无需处理昂贵的重写即可处理遗留代码的方法。那么新代码呢？

好吧，在您的情况下，您只想打印一些内容，只需执行以下操作：


这很简单，而且非常清晰。
然后慢慢冒出表面的一点是，存在get（）的用例）和isPresent（）。它们可以让您机械地修改现有代码，以使用较新的类型，而不必考虑太多。
因此，您在做什么，在以下方面会被误导：


您正在调用可能返回null的方法。正确的想法是该方法返回null。
您正在使用旧的创可贴方法来处理此可选方法，而不是使用包含lambda幻想的美味新方法。您应该做的很简单：

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

当然，它的漂亮版本看起来像：

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

顺便说一下，虽然它不是必需的，但我还是建议您在每次操作中使用新行，以便于阅读。
在一周的任何一天都易于阅读和理解节拍的简洁性。

这当然是一个非常简单的示例，在此示例中很容易理解我们正在尝试做的所有事情。在现实生活中并不总是那么简单。但是请注意，在此示例中，我们所表达的是我们的意图。我们想要获取员工，获取其ID，并在可能的情况下进行打印。这是Optional的第二大胜利。它使我们可以创建更清晰的代码。我也确实认为，做类似做一种方法的事情通常是个好主意，例如，做一个可以处理很多事情的方法，以便可以将其输入到地图中。

#7 楼

我看不到样式2的好处。
您仍然需要认识到需要空检查，现在它更大了，因此可读性更差。 .getEmployee（）将返回Optional，然后代码将变为：以某种方式处理可选值。并且，如果整个代码库中的方法从不返回null（或者几乎没有团队例外的规则），则它将增加针对NPE的安全性。

#8 楼

我认为最大的好处是，如果您的方法签名返回一个Employee，则无需检查null。您知道通过该签名可以保证遣返员工。您无需处理失败案例。使用可选件，您知道自己会做。

在代码中，我看到过空检查永远不会失败，因为人们不想跟踪代码来确定是否可能存在空，因此他们会在所有防御性位置抛出空检查。这会使代码变慢一些，但更重要的是，它会使代码更嘈杂。

但是，要使其正常工作，您需要一致地应用此模式。

#9 楼

我的答案是：只是不要。至少要三思而后行，这是否真的是一种改进。

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

这样的表达式（从另一个答案中获取）似乎是正确的处理本可为空的返回方法的功能方法。它看起来不错，它永远不会抛出，也永远不会让您考虑处理“缺席”案件。

它看起来比旧方法更好。

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

，这显然可以存在else子句。

功能样式


看起来完全不同（对于不习惯它的人来说是不可读的）
调试起来很痛苦
可以不能轻易扩展以处理“缺席”案例（orElse并不总是足够的）
误导了忽略“缺席”案例

在任何情况下都不应将其用作灵丹妙药。如果它是通用的，则应将.运算符的语义替换为?.运算符的语义，将NPE遗忘，并忽略所有问题。


虽然是Java迷，我必须说，函数风格只是Java人的一个可怜的人，用它来代替其他语言众所周知的语句。

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

我们是否同意该语句


（真的）不起作用？
与旧代码非常相似，只是简单得多？
更多比功能样式更具可读性？
调试器友好吗？

#10 楼

如果“ employeeService”本身为空，将会发生什么？在这两个代码段中，都会引发空指针异常。

无需使用可选的方法就可以处理该异常：

if(employeeServive != null) {
    Employee employee = employeeServive.getEmployee();
    if(employee!=null){
        System.out.println(employee.getId());
    }
}

您会看到有多个if检查，并且可以将其扩展为具有长嵌套结构的长层次结构，例如employeeService.getEmployee（）。​​getDepartment（）。getName（）.... getXXX（）。getYYY（）等。

要处理这种情况，我们可以使用Optional类，例如：

Optional.ofNullable(employeeService)
     .map(service -> service.getEmployee())
     .map(employee -> employee.getId())
     .ifPresent(System.out::println);

它可以处理任何大小的嵌套。

要全面了解Java Optional，请阅读有关该主题的文章：Java 8中的Optional

#11 楼

可选的是来自功能编程的概念（高阶类型）。使用它可以消除嵌套的null检查，并使您摆脱厄运金字塔。