Идеальным решением является разделение «команда-запрос»: создайте один метод (команду) для выполнения чего-либо со строкой, если она присутствует.И еще один метод (запрос), чтобы сказать вам, был ли он там.
Однако мы не живем идеальным миром, и идеальные решения никогда не возможны.Если в вашей ситуации вы не можете разделить команду и запрос, мне по вкусу идея, уже представленная shmosel: map для boolean
.В качестве детали я бы использовал filter
, а не внутренний оператор if
:
public boolean checkSomethingIfPresent() {
return mightReturnAString().filter(item -> item.equals("something"))
.map(item -> {
// Do some other stuff like use "something" in API calls
return true; // (compiles)
})
.orElse(false);
}
Что мне не нравится в этом, так это то, что цепочка вызовов имеет побочный эффект, который обычно не ожидаетсякроме ifPresent
и ifPresentOrElse
(и, конечно, orElseThrow
).
Если мы настаиваем на использовании ifPresent
, чтобы сделать побочный эффект более четким, это возможно:
AtomicBoolean result = new AtomicBoolean(false);
mightReturnAString().filter(item -> item.equals("something"))
.ifPresent(item -> {
// Do some other stuff like use "something" in API calls
result.set(true);
});
return result.get();
Я использую AtomicBoolean
в качестве контейнера для результата, поскольку нам не разрешено присваивать примитиву boolean
изнутри лямбды.Нам не нужна его атомарность, но она также не вредит.
Ссылка: Разделение команд и запросов в Википедии