Using Supplier instead of Optional as a method parameter

Question

I have an interface and its parameter can be null.

int count(@Nullable F filter);

To avoid null parameters and null-checks, common advice is to use the method overloading:

int count();
int count(@NonNull F filter);

In some cases, I don't like this approach, because it forces clients to make this kind of job:

F f = getFilter();
int count = f != null ? count(f) : count();

It much more convenient for client to use:

count(getFilter())

Optionals, at the first glance, can solve this problem but Optional should not be used for parameters https://rules.sonarsource.com/java/RSPEC-3553

So my question is: can I use Supplier instead?

// service code:
int count(Supplier<F> filter) {
    Optional.ofNullable(filter.get()).map(f -> count(f)).orElseGet(() -> count());
};
//client code:
count(() -> getFilter())

Or even

int count(Supplier<Optional<F>> filter)

Idea doesn't show any warnings.

I personally like my code after that, but isn't it cheating? Why it's better than Optional?

EDIT: Thanks for comments. I agree, in my case Supplier is just a sophisticated @Nullable approach.

I will return to:

int count();
int count(@NonNull F filter);
/////
getFilter().map(f -> count(f)).orElseGet(() -> count());

Your first example of using a `Supplier` is just a more complex way of using `@Nullable F`. You've just replaced the `@Nullable F` with something that can return a `@Nullable F`. The second example of using a `Supplier>` is a nasty way to fool Idea. — Rob Spoor, Aug 06 '22 at 14:58
@RobSpoor ok, but do we have an approach to give a nice interface to a client and avoid null checks at the same time? — Alexey, Aug 06 '22 at 15:03
@Alexey if your method accepts nulls there's no way around it: you'll have to check whether the parameter is `null`. — Federico klez Culloca, Aug 06 '22 at 15:05
`Optional.ofNullable` is not meant be used for `null`-checks, it's an abuse of Optional. Use **explicit** *null-check* (there's nothing wrong with it), instead of hiding it. — Alexander Ivanchenko, Aug 06 '22 at 15:08

score 2 · Accepted Answer · answered Aug 06 '22 at 16:01

If you don't want the client-code to dial with null, you can change the method getFilter() to return Optional<F>.

In this case, the code in the client would look like that:

int count = getFilter().map(MyClass::count).orElse(MyClass.count());

With this approach, your method count(F) doesn't require any extra logic.

If it feels like too complicated, then can implement count(F) in such a way that it would delegate to count() in case if provided argument is null.

Both your attempt with Supplier<F> and Supplier<Optional<F>> are artificial and seem to be driven by intention to circumvent Sonar, rather than by the real use cases.

Using Supplier instead of Optional as a method parameter

1 Answers1