最近,我与我的队友讨论了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
对于可选参数,只会使方法的约定更加明确。只需查看方法签名即可知道此参数是可选的,不需要读取javadocs。但是,Optional.absent()
当他不想使用该可选参数时,不应强迫他通过。
我的队友有不同的看法。他想对此进行空检查,因此迫使呼叫者始终通过Optional.<String>absent()
。他的观点是,为什么我们要传递一个null可选。而且getBooks("catalog123", Optional.absent())
看起来比更具可读性getBooks("catalog123", null)
。
此方法位于我们的一个库软件包中,并且由我们拥有的多个软件包使用。
您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
)。
重要的是一致性。您的班级之间的一致性就在您手中。与JDK的一致性意味着null
至少在可预见的将来(Optional
可能有一天JDK 8会使用)使用。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句