Возврат потока из уровня обслуживания [дубликат]

Если поток конечен и ожидается ожидаемая / нормальная операция для возвращаемых объектов, которые будут вызывать проверенное исключение, я всегда возвращаю коллекцию. Потому что, если вы собираетесь что-то делать на каждом из объектов, которые могут вызывать исключение проверки, вы будете ненавидеть поток. Один настоящий недостаток в потоках - я не могу справиться с проверенными исключениями изящно.

Теперь, возможно, это знак того, что вам не нужны проверенные исключения, что справедливо, но иногда они неизбежны.

У меня, вероятно, было бы 2 метода, один для возврата Collection и один, чтобы вернуть коллекцию как Stream.

class Team
{
    private List<Player> players = new ArrayList<>();

// ...

    public List<Player> getPlayers()
    {
        return Collections.unmodifiableList(players);
    }

    public Stream<Player> getPlayerStream()
    {
        return players.stream();
    }

}

Это лучшее из обоих миров. Клиент может выбрать, хотят ли они List или Stream, и им не нужно делать дополнительное создание объекта для создания неизменяемой копии списка, чтобы получить Stream.

Это также добавляет только 1 больше метода для вашего API, поэтому у вас не слишком много методов

Я думаю, это зависит от вашего сценария. Может быть, если вы сделаете свой Team вариант Iterable<Player>, этого достаточно.

for (Player player : team) {
    System.out.println(player);
}

или в функциональном стиле:

team.forEach(System.out::println);

Но если вы хотите более полный и свободный api, поток может быть хорошим решением.

Были ли потоки, которые всегда были «завершены» внутри того же выражения, в котором они были созданы?

Вот как они используются в большинстве примеров.

Примечание: возврат потока не отличается от возвращаемого Итератора (допускается с гораздо большей выразительностью)

IMHO лучшим решением является инкапсуляция, почему вы это делаете, а не возвратите коллекцию.

, например

public int playerCount();
public Player player(int n);

, или если вы намерены считать их

public int countPlayersWho(Predicate<? super Player> test);

У меня есть несколько моментов, чтобы добавить к превосходный ответ Брайана Гетца .

. Очень часто возвращать Stream из вызова метода стиля «getter». См. Страницу использования потока использования в Java 8 javadoc и найдите «методы ..., которые возвращают поток» для пакетов, отличных от java.util.Stream. Эти методы обычно относятся к классам, которые представляют или могут содержать несколько значений или агрегатов чего-либо. В таких случаях API обычно возвращают коллекции или массивы из них. По всем причинам, которые Брайан отметил в своем ответе, очень гибко добавлять сюда методы Stream-return. У многих из этих классов уже есть методы, основанные на коллекции или массиве, поскольку классы предшествуют API Streams. Если вы разрабатываете новый API, и имеет смысл предоставлять методы Stream-return, возможно, нет необходимости добавлять методы возврата коллекции.

Брайан упомянул стоимость «материализации» значения в коллекцию. Чтобы усилить этот момент, на самом деле существуют две затраты: стоимость хранения значений в коллекции (выделение и копирование памяти), а также стоимость создания значений в первую очередь. Последнюю стоимость часто можно уменьшить или избежать, воспользовавшись стремлением Stream к лени. Хорошим примером этого являются API-интерфейсы в java.nio.file.Files:

static Stream<String>  lines(path)
static List<String>    readAllLines(path)

Не только readAllLines должны хранить все содержимое файла в памяти, чтобы сохранить его в списке результатов, должен прочитать файл до самого конца, прежде чем он вернет список. Метод lines может вернуться почти сразу после того, как он выполнил некоторую настройку, оставив чтение файла и прерывание строки до тех пор, пока это будет необходимо - или совсем нет. Это огромное преимущество, если, например, вызывающий пользователь интересуется только в первых десяти строках:

try (Stream<String> lines = Files.lines(path)) {
    List<String> firstTen = lines.limit(10).collect(toList());
}

Конечно, значительное пространство памяти может быть сохранено, если вызывающий фильтр фильтрует поток, чтобы возвращать только строки, соответствующие шаблон и т. д.

. Идиома, которая, кажется, появляется, - это имя методов возврата потока после множественного числа имени того, что оно представляет или содержит, без префикса get. Кроме того, в то время как stream() является разумным именем для метода возврата потока, когда есть только один возможный набор значений, возвращаемых, иногда есть классы, которые имеют агрегаты нескольких типов значений. Например, предположим, что у вас есть объект, содержащий как атрибуты, так и элементы. Вы можете предоставить два API-интерфейса, возвращающих поток:

Stream<Attribute>  attributes();
Stream<Element>    elements();

В контексте команды / предприятия / многоразовых классов:

Обычно разрабатывают классы без учета того, что клиенты могут принять в отношении класса. Если вы вернете поток, вы вернете потенциально бесконечный список, и клиенты должны рассматривать это как потенциально бесконечный список. Это нарушение безопасности кода и хороший вкус для любого другого класса или другого метода для запуска stream.collect(toList()) в потоке, который он не создал сам, слепо предположив, что он будет конечным. Если это был желательный шаблон кода, потоки должны иметь некоторый метод, например isFinite(), чтобы защищать от ошибочных предположений.

Хуже того, возвращение потока во избежание материализации одинаково плохо, потому что кажется слишком легким материализует поток с .collect(), то есть пока класс обслуживания избегает материализации, у класса клиента может возникнуть соблазн сделать это с высокой стоимостью, в частности, если вы постоянно возвращаете потоки в качестве стиля кода и больше не можете сказать, какой поток возвращается должны быть материализованы, а какие - нет. Классические интерфейсы, которые указывают на плохую материализацию, - это java.util.Iterator (хотя commons-lang определяет IteratorUtils.toList ()).

Поэтому я бы рекомендовал использовать любой метод не-сбора, только если вы хотите документировать своим клиентам, что результат может быть бесконечным или может быть непригоден для материализации.

То, что потоки более удобны для функционального программирования, не означает, что они должны быть предпочтительными, это означает, что JDK должен расширить его API-интерфейс коллекции, позволяющий выполнять те же операции, чтобы клиентам не приходилось называть collection.stream().....

Для домашних заданий, строго личных проектов или другого неиспользованного кода

From простая алгоритмическая перспектива, игнорируя стиль кода, читабельность или проблемы OO-Design, предпочитая Streams, как в принятом ответе, в порядке. Но я не вижу, как это можно сделать общей рекомендацией по StackOverflow

Возможно, завод Stream станет лучшим выбором. Большая победа только разоблачения коллекций через Stream заключается в том, что он лучше инкапсулирует структуру данных вашей модели домена.

. Это также побуждает пользователей вашего класса домена писать код в более современном стиле Java 8. Это может быть полезно для любого использования ваших классов домена для воздействия на внутреннюю работу вашего списка или набора. , Можно поэтапно реорганизовать этот стиль, сохранив ваши существующие геттеры и добавив новые получатели Stream-возвращающихся. Со временем вы можете переписать свой устаревший код до тех пор, пока не удалите все получатели, которые возвращают список или набор. Этот вид рефакторинга кажется действительно хорошим после того, как вы очистили весь устаревший код!