Для меня вы сделали это слишком сложным. Вот гораздо более простой способ сделать это. Убедитесь, что ваш метод getItems()
возвращает пустой список, если нет элементов для возврата, чтобы вы могли обойтись без дополнительных нулевых проверок, как указано выше. Этот подход менее подвержен ошибкам и приводит к более читаемому коду. Если вы можете сделать то же самое для метода getErrors
, описанного выше, вы можете просто отказаться от filter(Objects::nonNull)
, и это еще больше упростит конвейер обработки потока.
String errorPresent = message.getItems().stream()
.map(Item::getErrors).filter(Objects::nonNull)
.map(List::size).filter(s -> s > 0)
.findAny().map(ignored -> "failure")
.orElse("success");
В качестве альтернативы вы можете использовать троичный оператор, чтобы сделать это.
String errorPresent = message.getItems().stream()
.map(Item::getErrors)
.filter(Objects::nonNull)
.anyMatch(e -> !e.isEmpty()) ? "failure" : "success";
Ну, вот не очень реальный применимый пример, но я думаю, что Вы получите идею. Если позволяет Вам делать много различных операций на объекте и обеспечивает удобство.
var truck = function() {
this.turnLeft = function {
// turn left
return this;
}
this.turnRight = function {
// turn right
return this;
}
this.goReallyFast = function {
// go fast!
return this;
}
};
// My get-away plan
var myTruck = new truck();
myTruck.turnLeft().turnRight().goReallyFast();
Быстрый интерфейс - http://en.wikipedia.org/wiki/Fluent_interface
Да я думаю, что это могло быть очень полезно, но как любой шаблон разработки должен только использоваться при необходимости
Редактирование: вот клиентский API Твиттера в c# с помощью быстрого интерфейса - http://code.google.com/p/tweetsharp/
Один пример, где это полезно, с небольшой вариацией на Вашу проблему — вместо того, чтобы возвратить тот же объект, Вы разрабатываете объект быть неизменны . Тогда Ваши функции уже все возвратятся новый экземпляр из того же типа, но со свойствами набор соответственно.
Это имеет много практического применения, особенно в области функционального программирования.
В то время как это не работает таким же образом Вашим примером (TBH, я никогда не видел сделанный тот путь прежде), , jQuery полагает, что "объединение в цепочку" очень полезно , и jQuery является в значительной степени критерием в эти дни когда дело доходит до веб-платформ JS... так да:-)
Для совсем другого (неOO) пример объединение в цепочку несколько походит конвейеры Unix . Каждый шаг канала Unix возвращает полное (измененное) содержание, подходящее для пересылки к следующему шагу:
cat file1 file2 | sort -n | awk '{print $2}' | sed 's/@/ at /g'
В JavaScript это подходит все время при навигации по DOM. В особенности при попытке пробраться путь через набор элементов, которые не имеют идентификаторов.
, Например, был вопрос на ТАК относительно нахождение первого элемента таблицы . Это может включить много циклов или объединенных в цепочку команд.
Все дети любят объединять в цепочку. Однако, по моему опыту, это должно использоваться с осторожностью, так как это может уменьшить удобочитаемость кода. Другими словами, сделайте то, что имеет смысл Вам и может быть понятно другим программистам, у которых есть основное знакомство с понятием..
Цепочка JavaScript может быть очень полезной, если вы хотите выполнить серию действий над одним объектом. Я согласен с Майклом Лутоном, приведенным ниже, с цепочкой следует обращаться осторожно. Если вы добавите один или два связанных метода к объекту, который все еще доступен для чтения. Если вы начнете добавлять четыре, пять или даже девять, ваш код станет сложнее не только читать, но и поддерживать.