фон

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

Выберите точку сравнения-базовая функциональность

используя основные понятия, C# ' s IEnumerable понятие более тесно связано с Java Iterable, который способен создать как можно больше итераторы как вы хотите. IEnumerables создать IEnumerators. В Java Iterable создать Iterators

история каждого понятия схожа, в том, что оба IEnumerable и Iterable есть основная мотивация, чтобы позволить "для каждого" стиль цикла над членами коллекций данных. Это чрезмерное упрощение, поскольку они оба позволяют больше, чем просто это, и они также достигли этой стадии через разные прогрессии, но это значительная общая черта независимо.

давайте сравним эту функцию: в обоих языки, если класс реализует IEnumerable/Iterable, то этот класс должен реализовать хотя бы один метод (для C# это GetEnumerator и для Java-это iterator()). В каждом случае экземпляр возвращается из этого (IEnumerator/Iterator) позволяет получить доступ к текущим и последующим членам данных. Эта функция используется в синтаксисе для каждого языка.

Выберите свою точку сравнения-расширенная функциональность

IEnumerable В C# был расширен, чтобы разрешить ряд других языковых особенностей ( в основном связано с Linq). Добавленные функции включают в себя выборки, проекции, агрегации и т. д. Эти расширения имеют сильную мотивацию от использования в теории множеств, аналогичной концепциям SQL и реляционных баз данных.

Java 8 также имеет функциональность, добавленную для обеспечения степени функционального программирования с использованием потоков и лямбд. Обратите внимание, что потоки Java 8 в основном мотивированы не теорией множеств, а функциональным программированием. Не обращающий внимания, есть много параллелей.

Итак, это второй момент. Усовершенствования, внесенные в C# были реализованы в качестве расширения к

Stream s построены вокруг Spliterators, которые являются статусными, изменяемыми объектами. У них нет действия" сброса", и на самом деле, требуя поддержки такого действия перемотки,"отнимет много энергии". Как бы Random.ints() предполагается обрабатывать такой запрос?

С другой стороны, для StreamS, которая имеет уточняющей происхождения, это легко построить эквивалентную Stream для повторного использования. Просто поместите шаги, сделанные для построения Stream в многоразовые метод. Имейте в виду, что повторение этих шагов не является дорогостоящей операцией, поскольку все эти шаги являются ленивыми операциями; фактическая работа начинается с операции терминала, и в зависимости от фактической операции терминала может выполняться совершенно другой код.

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

---

кстати, во избежание путаницы, терминальная операция потребляет the Stream, который отличается от закрытие the Stream как вызов close() на потоке делает (что требуется для потоков, имеющих связанные ресурсы, такие как, например, произведенные Files.lines()).

---

кажется, что a много путаницы проистекает из ошибочного сравнения IEnumerable С Stream. Ан IEnumerable представляет возможность предоставить фактический IEnumerator, так как Iterable в Java. В отличие от этого,Stream является своего рода итератором и сравним с IEnumerator поэтому неправильно утверждать, что этот тип данных может использоваться несколько раз в .NET, поддержка IEnumerator.Reset не является обязательным. Примеры, обсуждаемые здесь, скорее используют тот факт, что IEnumerable можно использовать для извлечения новая IEnumerators и это работает с Java Collections Также; вы можете получить новый Stream. Если разработчики Java решили добавить Stream операции Iterable непосредственно, с промежуточными операциями, возвращающими другой Iterable, это было действительно сопоставимо, и это может работать так же.

однако, разработчики решили, против него и решение обсуждается в этот вопрос. Самый большой момент-путаница с нетерпеливыми операциями сбора и ленивыми Потоковые операции. Глядя на .NET API, я (да, лично) считаю это оправданным. Хотя это выглядит разумно, глядя на IEnumerable в одиночку, конкретная коллекция будет иметь много методов, манипулирующих коллекцией напрямую и много методов, возвращающих ленивый IEnumerable, в то время как специфика метода не всегда интуитивно понятна. Худший пример, который я нашел (в течение нескольких минут я смотрел на это)List.Reverse() чье имя совпадает ровно имя унаследованного (это правильный конец для методов расширения?)Enumerable.Reverse() при этом имея совершенно противоречивое поведение.

---

конечно, это два разных решения. Первый, чтобы сделать Stream тип, отличный от Iterable/Collection и второй Stream своего рода один итератор времени, а не другой вид итераций. Но эти решения были приняты вместе, и это может быть так, что разделение этих двух решений никогда не считался. Он не был создан с тем, чтобы быть сопоставимым с .NET в виду.

фактическое проектное решение API состояло в том, чтобы добавить улучшенный тип итератора,Spliterator. Spliterator s может быть обеспечено старым Iterables (именно так они были модернизированы) или совершенно новые реализации. Тогда,Stream был добавлен в качестве интерфейса высокого уровня к довольно низкому уровню Spliterators. Вот и все. Вы можете обсудить, будет ли другой дизайн лучше, но это не так продуктивно, это не изменится, учитывая то, как они разработаны сейчас.

есть еще один аспект реализации вы должны рассмотреть. StreamС не неизменяемые структуры данных. Каждая промежуточная операция может возвращать новый Stream экземпляр, инкапсулирующий старый, но он также может манипулировать своим собственным экземпляром вместо этого и возвращать себя (что не исключает выполнения даже обоих для одной и той же операции). Общеизвестными примерами являются такие операции, как parallel или unordered которые не добавляют еще один шаг, но манипулируют всем конвейером). Имея такую изменяемую структуру данных и попытки повторного использования (или еще хуже, используя его несколько раз одновременно) не играет хорошо...

---

для полноты, вот ваш пример quicksort переведен на Java Stream API. Это показывает, что на самом деле это не "отнимает много сил".

static Stream<Integer> quickSort(Supplier<Stream<Integer>> ints) {

  final Optional<Integer> optPivot = ints.get().findAny();
  if(!optPivot.isPresent()) return Stream.empty();

  final int pivot = optPivot.get();

  Supplier<Stream<Integer>> lt = ()->ints.get().filter(i -> i < pivot);
  Supplier<Stream<Integer>> gt = ()->ints.get().filter(i -> i > pivot);

  return Stream.of(quickSort(lt), Stream.of(pivot), quickSort(gt)).flatMap(s->s);
}

его можно использовать как

List<Integer> l=new Random().ints(100, 0, 1000).boxed().collect(Collectors.toList());
System.out.println(l);
System.out.println(quickSort(l::stream)
    .map(Object::toString).collect(Collectors.joining(", ")));

вы можете написать его еще более компактным как

static Stream<Integer> quickSort(Supplier<Stream<Integer>> ints) {
    return ints.get().findAny().map(pivot ->
         Stream.of(
                   quickSort(()->ints.get().filter(i -> i < pivot)),
                   Stream.of(pivot),
                   quickSort(()->ints.get().filter(i -> i > pivot)))
        .flatMap(s->s)).orElse(Stream.empty());
}

Я думаю, что есть очень мало различий между ними, когда вы смотрите достаточно внимательно.

в лицо,IEnumerable похоже, что это многоразовая конструкция:

IEnumerable<int> numbers = new int[] { 1, 2, 3, 4, 5 };

foreach (var n in numbers) {
    Console.WriteLine(n);
}

однако, компилятор на самом деле делает немного работы, чтобы нам помочь; он генерирует следующий код:

IEnumerable<int> numbers = new int[] { 1, 2, 3, 4, 5 };

IEnumerator<int> enumerator = numbers.GetEnumerator();
while (enumerator.MoveNext()) {
    Console.WriteLine(enumerator.Current);
}

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

---

чтобы лучше проиллюстрировать, что IEnumerable имеет (может иметь) ту же "функцию", что и поток Java, рассмотрим перечислимый, источник чисел которого не является статической коллекцией. Например, мы можем создать перечислимый объект, который генерирует последовательность из 5 случайных номера:

class Generator : IEnumerator<int> {
    Random _r;
    int _current;
    int _count = 0;

    public Generator(Random r) {
        _r = r;
    }

    public bool MoveNext() {
        _current= _r.Next();
        _count++;
        return _count <= 5;
    }

    public int Current {
        get { return _current; }
    }
 }

class RandomNumberStream : IEnumerable<int> {
    Random _r = new Random();
    public IEnumerator<int> GetEnumerator() {
        return new Generator(_r);
    }
    public IEnumerator IEnumerable.GetEnumerator() {
        return this.GetEnumerator();
    }
}

теперь у нас есть очень похожий код на предыдущий массив на основе enumerable, но со второй итерацией над numbers:

IEnumerable<int> numbers = new RandomNumberStream();

foreach (var n in numbers) {
    Console.WriteLine(n);
}
foreach (var n in numbers) {
    Console.WriteLine(n);
}

во второй раз мы повторяем numbers мы получим другую последовательность чисел, которая не может быть повторно использована в том же смысле. Или, мы могли бы написать RandomNumberStream чтобы бросить исключение, если вы попытаетесь повторить его несколько раз, что делает перечисляемый фактически непригодным (например, Java Поток.)

кроме того, что означает ваша перечислимая быстрая сортировка при применении к RandomNumberStream?

---

вывод

Итак, самое большое различие заключается в том, что .NET позволяет повторно использовать IEnumerable неявно создает новый IEnumerator в фоновом режиме, когда ему нужно будет получить доступ к элементам в последовательности.

это неявное поведение часто полезно (и "мощно", как вы заявляете), потому что мы можем многократно повторять коллекция.

но иногда, это неявное поведение может вызвать проблемы. Если ваш источник данных не статичен или является дорогостоящим для доступа (например, база данных или веб-сайт), то много предположений о IEnumerable должны быть отброшены; повторное использование не так прямолинейно

можно обойти некоторые из" запустить один раз " защиты в потоковом API; например, мы можем избежать java.lang.IllegalStateException исключения (с сообщением "поток уже был обработан или закрыт") путем ссылки и повторного использования Spliterator (вместо Stream напрямую).

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

    Spliterator<String> split = Stream.of("hello","world")
                                      .map(s->"prefix-"+s)
                                      .spliterator();

    Stream<String> replayable1 = StreamSupport.stream(split,false);
    Stream<String> replayable2 = StreamSupport.stream(split,false);


    replayable1.forEach(System.out::println);
    replayable2.forEach(System.out::println);

однако выход будет ограничен

prefix-hello
prefix-world

вместо того, чтобы повторять вывод дважды. Это потому что ArraySpliterator используется как Stream источник имеет статус и сохраняет свое текущее положение. Когда мы повторим это Stream мы начинаем снова в конце.

у нас есть несколько вариантов решения этой проблемы:

1. мы могли бы использовать апатриды Stream метод создания, например Stream#generate(). Мы должны были бы управлять состоянием извне в нашем собственном коде и сбросить между Stream "повторы":

   Spliterator<String> split = Stream.generate(this::nextValue)
                                     .map(s->"prefix-"+s)
                                     .spliterator();
   
   Stream<String> replayable1 = StreamSupport.stream(split,false);
   Stream<String> replayable2 = StreamSupport.stream(split,false);
   
   
   replayable1.forEach(System.out::println);
   this.resetCounter();
   replayable2.forEach(System.out::println);
   

2. другой (немного лучше, но не идеально) решение этой проблемы-написать наш собственный ArraySpliterator (или подобное Stream источник), который включает в себя некоторую емкость для сброса текущего счетчика. Если бы мы использовали его для создания Stream мы могли бы потенциально успешно анализировать их.

   MyArraySpliterator<String> arraySplit = new MyArraySpliterator("hello","world");
   Spliterator<String> split = StreamSupport.stream(arraySplit,false)
                                           .map(s->"prefix-"+s)
                                           .spliterator();
   
   Stream<String> replayable1 = StreamSupport.stream(split,false);
   Stream<String> replayable2 = StreamSupport.stream(split,false);
   
   
   replayable1.forEach(System.out::println);
   arraySplit.reset();
   replayable2.forEach(System.out::println);
   

3. лучшим решением этой проблемы (на мой взгляд) является создание новой копии любого состояния Spliterators используемый в Stream конвейер, когда новые операторы вызываются на Stream. Это еще не все сложный и вовлеченный в реализацию, но если вы не возражаете использовать сторонние библиотеки,Циклоп-реагировать есть Stream реализация, которая делает именно это. (Раскрытие информации: я являюсь ведущим разработчиком для этого проекта.)

   Stream<String> replayableStream = ReactiveSeq.of("hello","world")
                                                .map(s->"prefix-"+s);
   
   
   
   
   replayableStream.forEach(System.out::println);
   replayableStream.forEach(System.out::println);
   

выводит

prefix-hello
prefix-world
prefix-hello
prefix-world

как и ожидалось.