使用Supplier替代Optional作为方法参数是否可行？

原接口与常规重载方案 #

我有一个允许参数为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方案的限制 #

乍看之下，Optional似乎能解决这个问题，但根据Sonar规则RSPEC-3553，Optional不应作为方法参数使用。

Supplier方案的尝试 #

那能否改用Supplier作为参数？比如这样实现服务端代码：

// 服务端代码
int count(Supplier<F> filter) {
    Optional.ofNullable(filter.get()).map(f -> count(f)).orElseGet(() -> count());
};

客户端调用代码则为：

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());

内容的提问来源于stack exchange，提问作者Alexey