为什么使用可选的优先选择对变量进行空检查？

举两个代码示例：

if(optional.isPresent()) {
    //do your thing
}

if(variable != null) {
    //do your thing
}

据我所知，最明显的区别是Optional需要创建一个附加对象。

但是，许多人已经开始迅速采用Optionals。使用可选与空检查相比有什么优势？

Optional利用类型系统来完成您原本必须做的所有工作：记住给定的引用是否可能是null。很好 让编译器处理无聊的药物工作，并保留人类的思想来进行创造性，有趣的工作，总是很聪明的。

没有Optional，代码中的每个引用都像一颗未爆炸的炸弹。访问它可能会做一些有用的事情，否则它可能会异常终止您的程序。

使用Optional和不null使用，对普通引用的每次访问都会成功，并且对Optional的每次引用都会成功，除非未设置它并且您无法检查它。这是可维护性的巨大胜利。

不幸的是，现在提供的大多数语言Optional都没有废除null，因此您只能通过制定严格的“绝对不行”政策来从中受益null。因此，Optional例如在Java中，它不如理想中的那么引人注目。

An Optional带来了更强的键入操作的能力，这些操作可能会失败，正如其他答案所涵盖的那样，但这远未Optionals带来最有趣或最有价值的东西。更有用的是延迟或避免检查故障的能力，以及轻松地组合可能会失败的许多操作的能力。

考虑一下您是否有optional示例代码中的变量，那么您必须执行另外两个步骤，每个步骤都可能会失败。如果此过程中的任何步骤失败，则您想返回一个默认值。Optionals正确使用，您将得到如下结果：

return optional.flatMap(x -> x.anotherOptionalStep())
               .flatMap(x -> x.yetAnotherOptionalStep())
               .orElse(defaultValue);

随着null我将不得不检查三次，null继续前，这增加了很多的复杂性和维护问题的代码。 Optionals将检查内置到flatMap和orElse功能中。

请注意，我没有打过isPresent一次电话，使用时应将其视为代码气味Optionals。这并不一定意味着您永远不要使用isPresent，而应该仔细检查所有执行此操作的代码，以查看是否有更好的方法。否则，您是对的，与使用相比，您只会获得边际类型的安全好处null。

还要注意，我并不担心将所有内容封装到一个函数中，以保护代码的其他部分免受中间结果产生的空指针的影响。.orElse(defaultValue)例如，如果让我拥有另一个函数更有意义，那么将其放置在另一个函数中的烦恼就更少了，并且根据需要在不同函数之间组合操作会容易得多。

它强调了将null作为有效响应的可能性，人们经常认为（正确或错误）将不会返回null。突出显示几次有效为null的次数可以省去大量无意义的null检查。

理想情况下，将变量设置为null可能会导致编译时错误，但在可选位置除外；消除运行时空指针异常。遗憾的是，显然向后兼容排除了这种情况

让我给你举个例子：

class UserRepository {
     User findById(long id);
}

很清楚此方法的目的是什么。但是，如果存储库不包含具有给定ID的用户，会发生什么情况？它可能引发异常，或者可能返回null？

第二个例子：

class UserRepository {
     Optional<User> findById(long id);
}

现在，如果没有给定ID的用户在这里会发生什么？正确，您将获得Optional.absent（）实例，并且可以使用Optional.isPresent（）对其进行检查。使用Optional的方法签名更明确地约定其合同。立即清楚地知道该方法的行为方式。

在读取客户端代码时，它也有好处：

User user = userRepository.findById(userId).get();

我已经训练好自己的眼睛，以将.get（）视为立即的代码气味。这意味着客户端有意地忽略了所调用方法的协定。与不使用Optional相比，这要容易得多，因为在这种情况下，您不会立即知道被调用方法的约定（无论它允许返回null还是不允许返回），因此您需要首先进行检查。

可选与以下约定一起使用：具有可选返回类型的方法从不返回null，通常还与（较弱的）约定使用不具有可选返回类型的方法从不返回null（但最好使用@ Nonnull，@ NotNull或类似方法对其进行注释） 。

An Optional<T>允许您将“失败”或“无结果”作为方法的有效响应/返回值（例如，数据库查找）。使用a Optional代替使用null来指示失败/没有结果有一些优点：

• 它清楚地表明“失败” 是一种选择。您的方法的用户不必猜测是否null可能返回。
• null至少在我看来，该值不应用于表示任何内容，因为语义可能并不十分清楚。它应该用于告诉垃圾收集器可以收集先前引用的对象。
• 本Optional类提供了许多很好的方法来与值有条件地工作（例如，ifPresent()）或以透明的方式定义默认值（orElse()）。

不幸的是，null由于Optional对象本身可能仍然存在，因此并不能完全消除对代码进行检查的需要null。

除了其他答案外，Optionals在编写干净代码时的另一个主要优点是，可以在存在值的情况下使用Lambda表达式，如下所示：

opTr.ifPresent(tr -> transactions.put(tr.getTxid(), tr));

请考虑以下方法：

void dance(Person partner)

现在让我们看一些调用代码：

dance(null);

这会导致在其他地方可能难以跟踪崩溃，因为dance没有期望为空。

dance(optionalPerson)

这会导致编译错误，因为Dance期待的Person不是Optional<Person>

dance(optionalPerson.get())

如果我没有人，这将导致此行发生异常，这是我非法尝试将其转换为人的时候Optional<Person>。关键是，不同于传递空值，except跟踪到此处，而不是程序中的其他位置。

综上所述：滥用可选会更容易发现问题，滥用null会导致很难发现问题。

在Objective-C中，所有对象引用都是可选的。因此，像您发布的代码很愚蠢。

if (variable != nil) {
    [variable doThing];
}

上面的代码在Objective-C中是闻所未闻的。相反，程序员只是：

[variable doThing];

如果variable包含一个值，doThing则将对其进行调用。如果没有，则无害。该程序会将其视为无操作并继续运行。

这是可选的真正好处。您不必使用乱扔代码if (obj != nil)。

if（optional.isPresent（））{

这里最明显的问题是，如果“可选”真的是缺（即为空），那么你的代码将会有一个NullReferenceException（或类似）炸毁试图调用一个空对象引用的任何方法！

您可能想编写一个静态的Helper-class方法，该方法确定任何给定对象类型的空值，如下所示：

function isNull( object o ) 
{
   return ( null == o ); 
}

if ( isNull( optional ) ) ... 

或者，也许更有用：

function isNotNull( object o ) 
{
   return ( null != o ); 
}

if ( isNotNull( optional ) ) ... 

但是，其中任何一个真的比原始版本更具可读性/可理解性/可维护性吗？

if ( null == optional ) ... 
if ( null != optional ) ...