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

我们最近已经迁移到Java8。现在，我看到应用程序充斥着Optional对象。

Java 8之前（样式1）

Employee employee = employeeServive.getEmployee();

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

Java 8之后（样式2）

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

我看不到Optional<Employee> employeeOptional = employeeService.getEmployee();服务本身返回可选值时的附加值：

来自Java 6背景，我认为样式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));

如果您Optional用作仍可能返回的较旧API之间的“兼容性”层null，则在确定您拥有某些东西的最新阶段创建（非空）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

关键是您知道这里有一个非空的员工服务，因此您可以将其包装在Optionalwith中Optional.of()。然后，当您提出要求getEmployee()时，您可能会或可能不会雇用一名雇员。该员工可能有（或可能没有）ID。然后，如果最后得到一个ID，则要打印它。

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

具有Optional单个值的几乎没有附加值。如您所见，这只是用状态检查代替了检查null。

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

只要您使用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());

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

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其他人提供的方法。

当开发人员需要检查函数是否返回值时，使用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());

您的主要错误是您仍在使用更多程序性术语进行思考。这并不意味着对您作为一个人的批评，而仅仅是观察。用更多的功能性思维思考需要时间和实践，因此方法是现成的，看起来像是最明显的正确事物需要您的配合。您的第二个小错误是在方法内部创建Optional。Optional旨在帮助记录某些内容可能会或可能不会返回值的情况。您可能一无所获。

这使您确实编写了看起来清晰合理的完全清晰的代码，但是您被get和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的东西替换旧界面。为什么？因为正如其他人已经亲切地提到的那样： 这使人们不必猜测某些内容是否可以为null。 这已经被其他人指出。但是现在我们有一个问题。想象我们有（对不起，当我在一个无辜的方法上按下alt + F7时），在经过良好测试的旧代码中调用此方法的位置有46个，否则它将发挥出色的作用。现在，您必须更新所有这些。

这就是isPresent闪耀的地方。

因为现在：士力架lastSnickers = snickersCounter.lastConsumedSnickers（）; if（null == lastSnickers）{抛出新的NoSuchSnickersException（）; }其他{Consumer.giveDiabetes（lastSnickers）; }

变成：

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

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

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

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

snickersCounter.lastConsumedSnickers（）。ifPresent（System.out :: println）;

这很简单，也很清楚。然后慢慢浮出水面的是，存在get（）和isPresent（）的用例。它们的存在使您可以机械地修改现有代码以使用较新的类型，而不必考虑太多。因此，您在做的事情在以下方面会被误导：

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

如果您确实想将Optional用作简单的null安全检查，那么您应该做的就是：

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

当然，它的漂亮版本如下所示：

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

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

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

我看不到样式2的好处。您仍然需要意识到需要空检查，现在它更大了，因此可读性更差。

更好的样式是，如果employeeServive.getEmployee（）返回Optional，那么代码将变为：

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

这样，您将无法调用employloyeeServive.getEmployee（）。​​getId（），并且您会注意到应该以某种方式处理可选值。并且，如果在整个代码库中，方法从不返回null（或者几乎从不为您的团队所熟知的此规则例外）返回null，则可以提高针对NPE的安全性。

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

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

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

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

一个表达式（取自另一个答案）像

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));

从其他语言中广为人知。我们是否同意这一说法

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

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