另一个在传递Optional作为参数时要小心的原因是方法应该做一件事…如果你传递一个可选参数，你可以做不止一件事，它可以类似于传递一个布尔参数。

public void method(Optional<MyClass> param) {
     if(param.isPresent()) {
         //do something
     } else {
         //do some other
     }
 }

在一些涉及protobufs或在配置对象中设置字段的用例中，使用Optional作为参数可能很有用。

public void setParameters(Optional<A> op1, Optional<B> op2) {
    ProtoRequest.Builder builder = ProtoRequest.newBuilder();
    op1.ifPresent(builder::setOp1);
    op2.ifPresent(builder::setOp2);
...
}

我认为在这种情况下，使用可选参数可能会很有用。接收原型请求的API将处理不同的字段。 如果函数没有对这些参数进行额外的计算，那么使用Optional可能会更简单。

public void setParameters(A op1, B op2) {
    ProtoRequest.Builder builder = ProtoRequest.newBuilder();
    if (op1 != null) {
        builder.setOp1(op1);
    }
    if (op2 != null) {
        builder.setOp2(op2);
    }
...
}

还有一种方法，你能做的是

// get your optionals first
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

// bind values to a function
Supplier<Integer> calculatedValueSupplier = () -> { // your logic here using both optional as state}

一旦你构建了一个函数(在本例中是供应商)，你就可以将它作为任何其他变量传递，并能够使用它来调用

calculatedValueSupplier.apply();

这里的想法是，你是否有可选值将是你的函数的内部细节，而不是参数。将可选参数作为参数来考虑函数实际上是我发现的非常有用的技巧。

至于你的问题，你是否应该这样做，这是基于你的偏好，但正如其他人所说，它使你的API丑陋，至少可以说。

我认为这是因为您通常编写函数来操作数据，然后使用map和类似的函数将其提升为可选。这将添加默认的可选行为。 当然，在某些情况下，有必要编写自己的可用于Optional的辅助函数。

几乎没有理由不使用Optional作为参数。反对这一点的论点依赖于权威的论点(见Brian Goetz -他的论点是我们不能强制非空可选参数)或可选参数可能为空(本质上是相同的论点)。当然，Java中的任何引用都可以为空，我们需要鼓励规则由编译器执行，而不是由程序员的内存执行(这是有问题的，并且不能扩展)。

函数式编程语言鼓励可选参数。使用它的最佳方法之一是有多个可选参数，并使用liftM2来使用一个函数，假设参数不是空的并返回一个可选参数(参见http://www.functionaljava.org/javadoc/4.4/functionaljava/fj/data/Option.html#liftM2-fj.F-)。不幸的是，Java 8实现了一个非常有限的库，支持可选功能。

作为Java程序员，我们应该只使用null来与遗留库交互。

首先，如果你使用方法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;