В лямбда-тяжелых библиотеках до Java 8, таких как Guava, в выходных данных используются общие интерфейсы Java Collection Framework, поэтому их легко передавать во внешние / внутренние API-интерфейсы и при этом использовать некоторые ленивые вычисления, если это делает метод библиотеки (например, lazy filter()and transform()).
Тем не менее, в Java 8 Streams, вызов для получения Collection/ Mapявляется терминалом (т.е. нетерпеливым), и он также выделит новые структуры данных для хранения результатов.
Для сложных вычислений с несколькими этапами и схемой стратегии в середине это вызывает много ненужных распределений из-за промежуточных результатов.
Итак, думают ли люди, что для внутренних API (т.е. стратегий шаблонов стратегий) Streamрекомендуется брать и возвращать s, или я должен просто вернуться к ленивым, но не оптимизированным (каламбур, я думаю, что) API-интерфейсам Guava?
Редактировать:
Моя главная проблема Streamзаключается в том, что его можно употреблять только один раз, а передача чего-то вроде этого Supplier<Stream<X>>выглядит чрезвычайно громоздкой. Это почти подталкивает вас к тому, чтобы просто пройти, Collectionа затем повторить stream()(и оплатить стоимость тщательной оценки в этот момент).