Guava可选作为可选参数的方法参数
最近我与我的队友讨论了在方法中使用Guava Optional作为可选参数的问题。
让我们说方法是
List getBooks(String catalogId, Optional categoryId) { Validate.notNull(catalogId); Validate.notNull(categoryId); // Point of conflict. Is this required?
它接受一个catalogId和一个可选的 categoryId ，它返回该目录中列出的书籍，如果也传递了类别，则只返回该类别中的书籍。
冲突点是，Validating Optional categoryId进行空检查。 我认为不应该对它进行空检查，因为它是一个可选参数。 函数的调用者可以传递null或者Optional.absent()和getBooks函数应该通过在实现中执行if(categoryId==null && categoryId.isPresent())来处理这两种情况。
我的意见是， Optional参数的可选性只是使方法的合同更加清晰。 通过查看方法签名，可以告诉该参数是可选的，不需要读取javadoc。 但是当他不想使用那个可选参数时，他不应该被迫传递Optional.absent() 。
我的队友有不同的看法。 他想对它进行空检查，因此强制调用者总是传递Optional.absent() 。 他的观点是我们为什么要传递null可选。 此外， getBooks("catalog123", Optional.absent())看起来比getBooks("catalog123", null)更具可读性。
此方法位于我们的库包中，并由我们拥有的多个包使用。
对于此方案，您对Optional使用有何建议？
谢谢
对于此方案，您对Optional的使用有何建议？
避免。 避免。 避免。
虽然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的主要参数）。
重要的是一致性。 您class上的一致性就在您手中。 与JDK的一致性意味着使用null ，至少在可预见的将来（有一天JDK 8 Optional可能占优势）。