Ну а если говорить о rxJava, то ее суть — шина/цепочка/pipeline событий. Очень желательно чтоб передаваемые данные были immutable, иначе вся ответственность за его изменения ложится на вас.
Возьмем ваш пример применительно к rxJava.
Простейшая реализация:
Такт 1) Ячейка (испускатель событий) 1, испускает событие со своим новым значением.
Такт 2) Оно попадает в ячейку 2. Она его обрабатывает. В момент обработки, ячейка 1 испускает новый объект данных.
Такт 3) В ячейку 2 приходят новые данные. Она их обрабатывает.
Реализация с backpressure buffer:
Такт 1) Ячейка (испускатель событий) 1, испускает событие со своим новым значением. Буффер ловит его и держит у себя не отпуская дальше.
Такт 2) Я1 испускает новое событие. Буффер опять его ловит.
… какое-то время спустя
Такт N) Буффер все накопленные событие кладет в список и передает его как список в Я2
Придумали для того чтоб реалзовать парадигму реактивного программирования.
Суть — передавать события по цепочке со всевозможными трансформациями по пути. Абстрактный пример — представте таблицу Excel. Вы изменили ячейку — это начальное событие. Но от этой ячейки зависит значение других ячеек — они слушают событие от первой ячейки, применяют его и рассылают событие что они изменились. У них так же могут быть слушатели… Это простой пример реализации реактивного программирования.
В кратце, я бы сказал, что Streams — для работы с коллекциями (по цепочке), rx — для работы с событиями (по цепочке). При том что у rx намного богаче функциональность.
В общем все зависит от того чего именно вам нужно добиться.
Вариант с массивом подойдет если нужно генерировать последовательность программно — например мы хотим сделать редактор танца. Минус — если нам для каждого метода надо передавать специфические для него данные — например для парсинга пользовательской корзины нам нужен пользовательский ИД, для оформления накладно- ИД корзины.
Да нормально мы ее воспринимаем. Только самым главным мотиватором для перехода на Scala были лямбды. А с 8й Java'ой такая необходимость отпала. Есть другие буонусы, но пока и так комфортно.
Я люблю Скалу, но 8я джава действительно решила главную проблему и проектов на скале сразу стало меньше.
Возьмем ваш пример применительно к rxJava.
Простейшая реализация:
Такт 1) Ячейка (испускатель событий) 1, испускает событие со своим новым значением.
Такт 2) Оно попадает в ячейку 2. Она его обрабатывает. В момент обработки, ячейка 1 испускает новый объект данных.
Такт 3) В ячейку 2 приходят новые данные. Она их обрабатывает.
Реализация с backpressure buffer:
Такт 1) Ячейка (испускатель событий) 1, испускает событие со своим новым значением. Буффер ловит его и держит у себя не отпуская дальше.
Такт 2) Я1 испускает новое событие. Буффер опять его ловит.
… какое-то время спустя
Такт N) Буффер все накопленные событие кладет в список и передает его как список в Я2
У rxJava очень наглядные картинки по каждому оператору. Посмотрите например
на debounce (раскройте там список rxJava в language specific) reactivex.io/documentation/operators/debounce.html#collapseRxJava
и group reactivex.io/documentation/operators/buffer.html
Суть — передавать события по цепочке со всевозможными трансформациями по пути. Абстрактный пример — представте таблицу Excel. Вы изменили ячейку — это начальное событие. Но от этой ячейки зависит значение других ячеек — они слушают событие от первой ячейки, применяют его и рассылают событие что они изменились. У них так же могут быть слушатели… Это простой пример реализации реактивного программирования.
Вариант с массивом подойдет если нужно генерировать последовательность программно — например мы хотим сделать редактор танца. Минус — если нам для каждого метода надо передавать специфические для него данные — например для парсинга пользовательской корзины нам нужен пользовательский ИД, для оформления накладно- ИД корзины.
Я люблю Скалу, но 8я джава действительно решила главную проблему и проектов на скале сразу стало меньше.