我在许多网站上读到过，Optional应该只用作返回类型，而不能用于方法参数中。我在努力寻找一个合乎逻辑的原因。例如，我有一个逻辑，它有两个可选参数。因此，我认为这样写我的方法签名是有意义的(解决方案1):
public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2) {
// my logic
}
许多网页指定Optional不应该用作方法参数。考虑到这一点，我可以使用下面的方法签名，并添加一个明确的Javadoc注释来指定参数可能为null，希望未来的维护者能够读取Javadoc，因此在使用参数之前总是执行null检查(解决方案2):
public int calculateSomething(String p1, BigDecimal p2) {
// my logic
}
或者，我可以用四个公共方法替换我的方法，以提供更好的接口，并使p1和p2是可选的(解决方案3):
public int calculateSomething() {
calculateSomething(null, null);
}
public int calculateSomething(String p1) {
calculateSomething(p1, null);
}
public int calculateSomething(BigDecimal p2) {
calculateSomething(null, p2);
}
public int calculateSomething(String p1, BigDecimal p2) {
// my logic
}
现在，我尝试编写为每种方法调用这段逻辑的类的代码。我首先从另一个返回Optionals的对象检索两个输入参数，然后调用calculatessomething。因此，如果使用解决方案1，调用代码将看起来像这样:
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1, p2);
如果使用解决方案2，调用代码看起来像这样:
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));
如果应用解决方案3，我可以使用上面的代码，也可以使用下面的代码(但它的代码明显更多):
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result;
if (p1.isPresent()) {
if (p2.isPresent()) {
result = myObject.calculateSomething(p1, p2);
} else {
result = myObject.calculateSomething(p1);
}
} else {
if (p2.isPresent()) {
result = myObject.calculateSomething(p2);
} else {
result = myObject.calculateSomething();
}
}
所以我的问题是:为什么使用可选项作为方法参数被认为是不好的做法(参见解决方案1)?对我来说，这看起来是最易读的解决方案，并且对于未来的维护者来说，参数可以是空的/null是最明显的。(我知道Optional的设计者只打算将其用作返回类型，但我找不到在这种情况下不使用它的任何逻辑理由)。
让我们明确一点:在其他语言中，并没有反对将Maybe类型用作字段类型、构造函数形参类型、方法形参类型或函数形参类型的一般建议。
因此，如果您“不应该”在Java中使用Optional作为参数类型，原因是特定于Optional或Java或两者。
可能适用于其他Maybe类型或其他语言的推理在这里可能是无效的。
根据Brian Goetz，
[W]e did have a clear
intention when adding [Optional], and it was not to be a general
purpose Maybe type, as much as many people would have liked us to do
so. Our intention was to provide a limited mechanism for library
method return types where there needed to be a clear way to represent
"no result", and using null for such was overwhelmingly likely to
cause errors.
For example, you probably should never use it for something that
returns an array of results, or a list of results; instead return an
empty array or list. You should almost never use it as a field of
something or a method parameter.
所以答案是针对Optional的:它不是“一般用途的可能类型”;因此，它是有限制的，而且限制的方式可能限制了它作为字段类型或参数类型的用处。
也就是说，在实践中，我很少发现使用Optional作为字段类型或参数类型是一个问题。如果Optional(尽管有局限性)作为参数类型或字段类型用于您的用例，请使用它。
首先，如果你使用方法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;
