我知道这个问题更多的是意见而不是事实。但是我最近从一个。net开发人员转变为java开发人员，所以我最近才加入了可选的一方。此外，我更喜欢把它作为一个评论，但由于我的分数水平不允许我评论，我被迫把它作为一个答案。

我一直在做的，这是我的经验之谈。是使用可选项作为返回类型，并且仅使用可选项作为参数，如果我需要可选项的值，以及可选项是否在方法中有值。

如果我只关心值，我在调用方法之前检查isPresent，如果我在方法中有某种日志记录或不同的逻辑，这取决于值是否存在，那么我将愉快地传入Optional。

起初，我也倾向于将optional作为参数传递，但如果从API-Designer透视图切换到API-User透视图，就会看到缺点。

对于你的例子，每个参数都是可选的，我建议将计算方法更改为一个自己的类，如下所示:

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

MyCalculator mc = new MyCalculator();
p1.map(mc::setP1);
p2.map(mc::setP2);
int result = mc.calculate();

一个很好的例子是可选的参数会很好是JPA存储库。我喜欢做一些像findbynameand姓氏(可选，可选)。这样，如果Optional为空，则不执行WHERE param=y

首先，如果你使用方法3，你可以用下面的代码替换最后14行代码:

int result = myobject . calculatessomething (p1.orElse(null)， p2.orElse(null));

您编写的四个变体是方便的方法。你应该只在更方便的时候使用它们。这也是最好的方法。这样，API就非常清楚哪些成员是必要的，哪些不是。如果你不想写四个方法，你可以通过参数的命名来澄清:

(String p1OrNull, BigDecimal p2OrNull)

这样，就很清楚允许空值。

p1.orElse(null)的使用说明了我们的代码在使用Optional时是多么冗长，这也是我避免使用它的部分原因。Optional是为函数式编程而编写的。流需要它。你的方法可能永远不应该返回Optional，除非在函数式编程中有必要使用它们。有一些方法，如option . flatmap()方法，需要对返回Optional的函数的引用。这是它的签名:

public <U>可选<U> flatMap(Function<?超级T， ?扩展了可选的< ?扩展U>>映射器)

这通常是编写返回Optional的方法的唯一理由。但即使在那里，也可以避免。您可以将一个不返回Optional的getter传递给flatMap()这样的方法，方法是将它包装在另一个将函数转换为正确类型的方法中。包装器方法看起来像这样:

public static <T, U> Function<? super T, Optional<U>> optFun(Function<T, U> function) {
    return t -> Optional.ofNullable(function.apply(t));
}

假设你有一个这样的getter:

你不能像这样把它传递给flatMap:

opt.flatMap(Widget::getName) //不工作!

但你可以这样传递:

opt.flatMap(小部件::getter) //工作得很好!

在函数式编程之外，应该避免使用可选项。

Brian Goetz说得很好:

将Optional添加到Java的原因是:

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

比这个更干净:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;

带有Optional的模式是为了避免返回null。将null传递给方法仍然是完全可能的。

虽然这些注释还不是正式的，但您可以使用JSR-308样式注释来指示是否接受函数中的空值。请注意，您必须有正确的工具来实际识别它，它将提供更多的静态检查而不是可执行的运行时策略，但它将有所帮助。

public int calculateSomething(@NotNull final String p1, @NotNull final String p2) {}

这是因为我们对API用户和API开发人员有不同的要求。

开发人员负责提供精确的规范和正确的实现。因此，如果开发人员已经意识到一个参数是可选的，那么实现必须正确地处理它，无论它是null还是optional。API应该对用户尽可能简单，null是最简单的。

另一方面，结果从API开发人员传递给用户。尽管规范是完整和冗长的，但仍然有可能用户没有意识到它或只是懒得处理它。在这种情况下，Optional结果迫使用户编写一些额外的代码来处理可能为空的结果。