Question

最近，我与我的队友讨论了如何在方法中使用Guava Optional作为可选参数。

让我们说方法是

List<Book> getBooks(String catalogId, Optional<String> categoryId) {
     Validate.notNull(catalogId);
     Validate.notNull(categoryId); // Point of conflict. Is this required?

接受catalogId和可选 categoryId，它会返回该目录中列出的图书，如果类别也通过，则只返回该类别中的图书。

冲突点是，验证Optional<String> categoryId进行空检查。我认为不应该对它进行空检查，因为它是一个可选参数。函数的调用者可以通过null或Optional.<String>absent()，getBooks函数应该通过在实现中执行if(categoryId==null && categoryId.isPresent())来处理这两种情况。

我的意见是，Optional可选参数只是使方法的合同更加清晰。通过查看方法签名，可以告诉该参数是可选的，并且不需要读取javadoc。但是当他不想使用那个可选参数时，他不应该被迫通过Optional.absent()。

我的队友有不同的看法。他想对它进行空检查，因此强制调用者始终通过Optional.<String>absent()。他的观点是我们为什么要传递null可选。此外，getBooks("catalog123", Optional.absent())看起来比getBooks("catalog123", null)更具可读性。

此方法位于我们的某个库包中，并由我们拥有的多个包使用。

对于此方案，您对Optional的使用有何建议？

由于

Answer 1

您对此方案的“可选”使用有何建议？

避免。避免。避免。

虽然Optional是很酷的替代到null，但在Java中，您最终会将其作为错误添加。正如Seelenvirtuose所写，有三种可能性，你只需要两种。正如JB Nizet所写，它最好用作返回值，它会提醒调用者所需的检查。作为方法论证，它没有任何帮助。

理想情况下，可选参数只是可选的，如

getBooks(String catalogId, String categoryId = null)

这不是有效的Java。 AFAIK C ++编译器将其转换为两种方法

getBooks(String catalogId, String categoryId)
getBooks(String catalogId)

这是你自己用Java编写的。抛出参数是明确表明它是可选的最明确的方法。将可选参数标记为@Nullable几乎同样好。使用可空性检查工具可以帮助您避免NPE（这是Optional的主要参数）。

重要的是一致性。您的课程的一致性掌握在您手中。与JDK的一致性意味着使用null，至少在可预见的将来（JDK 8 Optional可能会占上一天）。

Guava可选作为可选参数的方法参数

1 个答案: