使用供应者而不是可选参数作为方法参数
使用供应者而不是可选参数作为方法参数
提问于 2022-08-06 14:53:18
我有一个接口，它的参数可以是null。
int count(@Nullable F filter);为了避免null参数和空检查，常见的建议是使用重载方法：
int count();
int count(@NonNull F filter);在某些情况下，我不喜欢这种方法，因为它迫使客户做这种工作：
F f = getFilter();
int count = f != null ? count(f) : count();对于客户端来说，使用以下功能要方便得多：
count(getFilter())乍一看，选项可以解决这个问题，但是Optional不应该用于参数https://rules.sonarsource.com/java/RSPEC-3553。
所以我的问题是:我可以用Supplier代替吗？
// service code:
int count(Supplier<F> filter) {
Optional.ofNullable(filter.get()).map(f -> count(f)).orElseGet(() -> count());
};
//client code:
count(() -> getFilter())甚至
int count(Supplier<Optional<F>> filter)Idea没有显示任何警告。
在那之后，我个人喜欢我的代码，但这不是作弊吗？为什么它比Optional好
编辑：，谢谢你的评论。我同意，在我的例子中，Supplier只是一种复杂的@Nullable方法。
我将回到：
int count();
int count(@NonNull F filter);
/////
getFilter().map(f -> count(f)).orElseGet(() -> count());回答 1
Stack Overflow用户
回答已采纳
发布于 2022-08-06 16:01:12
如果不希望客户端代码使用null拨号，可以将getFilter()方法更改为返回Optional<F>。
在这种情况下，客户机中的代码如下所示：
int count = getFilter().map(MyClass::count).orElse(MyClass.count());使用这种方法，您的方法count(F)不需要任何额外的逻辑。
如果感觉太复杂，那么就可以以这样一种方式实现count(F)，即如果提供的参数是null，它将委托给count()。
您对Supplier<F>和Supplier<Optional<F>>的尝试都是人为的，似乎是出于规避Sonar的意图，而不是实际的用例。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/73260794
复制相关文章
相似问题
腾讯云开发者
