Реактивное программирование

В вычислительной технике реактивное программирование — это парадигма декларативного программирования, связанная с потоками данных и распространением изменений. С помощью этой парадигмы можно с легкостью выражать статические (например, массивы) или динамические (например, генераторы событий) потоки данных, а также сообщать о существовании предполагаемой зависимости в связанной модели выполнения, что облегчает автоматическое распространение измененных данных. поток данных.

Например, в условиях императивного программирования : a := b + c будет означать, что a присваивается результат b + c в момент вычисления выражения, а затем значения b и c можно изменить, не влияя на стоимость a. С другой стороны, в реактивном программировании значение a автоматически обновляется всякий раз, когда значения b или c измениться без необходимости явно переформулировать оператор a := b + c переназначить значение a.

вар   b   =   1 
 вар   c   =   2 
 вар   a   =   b   +   c 
 b   =   10 
 консоль  .   log  (  a  )   // 3 (а не 12, потому что "=" не является реактивным оператором присваивания) 

 // теперь представьте, что у вас есть специальный оператор "$=", который изменяет значение переменной (выполняет код в правой части оператор и присваивает результат левой переменной) не только при явной инициализации, но и при изменении ссылочных переменных (в правой части оператора) 
 var   b   =   1 
 var   c   =   2 
 var   a   $  =   b   +   c 
 b   =   10 
 console  .   журнал  (  а  )   // 12 

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

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

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

Подходы к созданию реактивных языков программирования

При создании реактивных языков программирования используется несколько популярных подходов. Одним из подходов является спецификация выделенных языков, специфичных для различных ограничений предметной области . Такие ограничения обычно характеризуются встроенными вычислениями в реальном времени или описанием аппаратного обеспечения. Другой подход предполагает определение языков общего назначения , включающих поддержку реактивности. Другие подходы сформулированы в определении и использовании библиотек программирования или встроенных предметно-ориентированных языков , которые обеспечивают реактивность наряду с языком программирования или поверх него. Спецификация и использование этих различных подходов приводит к компромиссу в языковых возможностях . В общем, чем более ограничен язык, тем больше связанных с ним компиляторов и инструментов анализа могут информировать разработчиков (например, при выполнении анализа того, могут ли программы выполняться в реальном времени). Функциональные компромиссы в отношении специфики могут привести к ухудшению общей применимости языка.

Модели программирования и семантика

Реактивное программирование управляется множеством моделей и семантики. Мы можем условно разделить их по следующим измерениям:

• Синхронность: синхронная и асинхронная модели времени
• Детерминизм: детерминированный и недетерминированный процесс и результаты оценки.
• Процесс обновления: обратный вызов , поток данных и актер

Методы

Суть реализаций

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

Изменить алгоритмы распространения

Наиболее распространенными подходами к распространению данных являются:

• Притяжение : Потребитель значений на самом деле является активным , поскольку он регулярно запрашивает наблюдаемый источник значений и реагирует всякий раз, когда соответствующее значение доступно. Такая практика регулярной проверки событий или изменений значений обычно называется опросом .
• Push : потребитель значения получает значение из источника всякий раз, когда значение становится доступным. Эти значения являются самостоятельными, например, они содержат всю необходимую информацию, и потребителю не требуется запрашивать дополнительную информацию.
• Push-pull : потребитель значения получает уведомление об изменении , которое представляет собой краткое описание изменения, например «некоторые значения изменены» — это часть push . Однако уведомление не содержит всей необходимой информации (что означает, что оно не содержит фактических значений), поэтому потребителю необходимо запросить у источника дополнительную информацию (конкретное значение) после получения уведомления — это извлечения часть . . Этот метод обычно используется, когда существует большой объем данных, которые потенциально могут быть интересны потребителям. Поэтому, чтобы снизить пропускную способность и задержку, отправляются только легкие уведомления; и тогда те потребители, которым требуется дополнительная информация, будут запрашивать именно эту конкретную информацию. Этот подход также имеет тот недостаток, что источник может быть перегружен множеством запросов на дополнительную информацию после отправки уведомления.

Что нажать?

На уровне реализации реакция на событие состоит из распространения информации по графу, которая характеризует наличие изменения. Следовательно, вычисления, на которые влияют такие изменения, устаревают и должны быть помечены для повторного выполнения. Такие вычисления обычно характеризуются транзитивным закрытием изменения (т.е. полного набора транзитивных зависимостей, на которые влияет источник) в связанном с ним источнике. Распространение изменений может затем привести к обновлению значений стоков графа .

Информация, распространяемая графом, может состоять из полного состояния узла, т. е. результата вычисления задействованного узла. В таких случаях предыдущий вывод узла игнорируется. Другой метод включает в себя дельта-распространение , т.е. постепенное распространение изменений . графа В этом случае информация распространяется вдоль ребер , которые состоят только из дельт , описывающих, как был изменен предыдущий узел. Этот подход особенно важен, когда узлы содержат большие объемы данных о состоянии , пересчитывать которые с нуля в противном случае было бы дорого.

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

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

используются два основных способа При построении графа зависимостей :

1. Граф зависимостей поддерживается неявно внутри цикла событий . Регистрация явных обратных вызовов приводит затем к созданию неявных зависимостей. Таким образом, инверсия управления , вызванная обратным вызовом, остается на месте. Однако для того, чтобы сделать обратные вызовы функциональными (т. е. возвращать значение состояния вместо значения единицы измерения), необходимо, чтобы такие обратные вызовы стали композиционными.
2. Граф зависимостей зависит от программы и создается программистом. обратным вызовом Это облегчает обращение к инверсии управления двумя способами: либо граф задается явно (обычно с использованием предметно-ориентированного языка (DSL), который может быть встроен), либо граф неявно определяется с помощью выражения и генерации с использованием эффективного метода. , архетипический язык .

в реактивном

Глюки

При распространении изменений можно выбрать такой порядок распространения, чтобы значение выражения не было естественным следствием исходной программы. Мы можем легко проиллюстрировать это на примере. Предполагать seconds— это реактивное значение, которое меняется каждую секунду и представляет текущее время (в секундах). Рассмотрим это выражение:

т = секунды + 1
 г = (т > секунд)
 

Потому что t всегда должно быть больше, чем seconds, это выражение всегда должно иметь истинное значение. К сожалению, это может зависеть от порядка оценки. Когда seconds изменения, необходимо обновить два выражения: seconds + 1и условное. Если первое вычислено раньше второго, то этот инвариант сохранится. Однако если сначала выполняются условные обновления, используя старое значение t и новое значение seconds, то выражение примет ложное значение. Это называется глюк .

Некоторые реактивные языки не содержат сбоев и доказывают это свойство. . Обычно это достигается путем топологической сортировки выражений и обновления значений в топологическом порядке. Однако это может иметь последствия для производительности, например задержку доставки значений (из-за порядка распространения). Поэтому в некоторых случаях реактивные языки допускают сбои, и разработчики должны осознавать возможность того, что значения могут временно не соответствовать исходному коду программы и что некоторые выражения могут вычисляться несколько раз (например, t > seconds может оцениваться дважды: один раз, когда новое значение seconds приедет, и еще раз, когда t обновления).

Циклические зависимости

Топологическая сортировка зависимостей зависит от того, является ли граф зависимостей ориентированным ациклическим графом (DAG). На практике программа может определить граф зависимостей, содержащий циклы. Обычно реактивные языки программирования ожидают, что такие циклы будут «разрывы», путем размещения некоторого элемента вдоль «заднего края», чтобы позволить реактивному обновлению завершиться. Обычно языки предоставляют такой оператор, как delay который используется механизмом обновления для этой цели, поскольку delay подразумевает, что последующее должно быть оценено на «следующем временном шаге» (что позволит завершить текущую оценку).

Взаимодействие с изменяемым состоянием

Реактивные языки обычно предполагают, что их выражения являются чисто функциональными . Это позволяет механизму обновления выбирать разные порядки выполнения обновлений и оставлять конкретный порядок неуказанным (тем самым обеспечивая оптимизацию). Однако когда реактивный язык встроен в язык программирования с состоянием, программисты могут выполнять изменяемые операции. Как сделать это взаимодействие гладким, остается открытой проблемой.

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

• Язык может предлагать понятие «изменяемой ячейки». Изменяемая ячейка — это ячейка, о которой знает система реактивного обновления, поэтому изменения, внесенные в ячейку, распространяются на остальную часть реактивной программы. Это позволяет нереактивной части программы выполнять традиционную мутацию, в то же время позволяя реактивному коду узнавать об этом обновлении и реагировать на него, тем самым поддерживая согласованность отношений между значениями в программе. Примером реактивного языка, предоставляющего такую ​​ячейку, является FrTime.
• Правильно инкапсулированные объектно-ориентированные библиотеки предлагают инкапсулированное понятие состояния. Поэтому в принципе такая библиотека может беспрепятственно взаимодействовать с реактивной частью языка. Например, в геттеры объектно-ориентированной библиотеки можно установить обратные вызовы, чтобы уведомлять механизм реактивного обновления об изменениях состояния, а изменения в реактивном компоненте можно передать в объектно-ориентированную библиотеку через геттеры. FrTime использует такую ​​стратегию.

Динамическое обновление графика зависимостей

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

т =
   if ((секунд по модулю 2) == 0):
     секунды + 1
   еще:
     секунды - 1
   конец
 т + 1
 

Каждую секунду значение этого выражения меняется на другое реактивное выражение, которое t + 1тогда зависит от. Поэтому граф зависимостей обновляется каждую секунду.

Разрешение динамического обновления зависимостей обеспечивает значительную выразительную силу (например, динамические зависимости обычно возникают в программах с графическим пользовательским интерфейсом (GUI)). Однако механизм реактивного обновления должен решить, восстанавливать ли выражения каждый раз или оставить узел выражения созданным, но неактивным; в последнем случае убедитесь, что они не участвуют в вычислениях, когда они не должны быть активными.

Концепции

Степени ясности

Языки реактивного программирования могут варьироваться от очень явных, в которых потоки данных настраиваются с помощью стрелок, до неявных, в которых потоки данных формируются из языковых конструкций, похожих на конструкции императивного или функционального программирования. Например, в неявно поднятом функционально-реактивном программировании (FRP) вызов функции может неявно вызвать создание узла в графе потока данных. Библиотеки реактивного программирования для динамических языков (такие как библиотеки Lisp «Cells» и Python «Trellis») могут создавать граф зависимостей на основе анализа во время выполнения значений, считываемых во время выполнения функции, что позволяет спецификациям потока данных быть как неявными, так и динамическими.

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

Статический или динамический

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

Использование переключателей данных в графе потока данных может в некоторой степени сделать статический граф потока данных динамическим и слегка размыть различия. Однако настоящее динамическое реактивное программирование может использовать императивное программирование для восстановления графа потока данных.

Реактивное программирование высшего порядка

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

Дифференциация потоков данных

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

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

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

реактивного

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

Простое распространение изменения с помощью стека может оказаться проблематичным из-за потенциальной экспоненциальной сложности обновления, если структура данных имеет определенную форму. Одну такую ​​форму можно описать как «повторяющуюся форму ромба» и она имеет следующую структуру: An _позже →B _n →A _n+1 , An _→ C _n →A _n+1 , где n=1,2... Эту проблему можно решить путем распространения недействительности только тогда, когда некоторые данные еще не признаны недействительными, и при необходимости повторно проверить данные, используя отложенную оценку .

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

С другой стороны, реактивное программирование — это форма того, что можно назвать «явным параллелизмом». и, следовательно, может быть полезным для использования мощности параллельного оборудования.

Сходства с паттерном наблюдателя

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

Подходы

Императив

Реактивное программирование можно объединить с обычным императивным программированием . В такой парадигме императивные программы работают с реактивными структурами данных. Такая установка аналогична программированию с императивными ограничениями ; однако, в то время как императивное программирование ограничений управляет двунаправленными ограничениями потока данных, императивное реактивное программирование управляет односторонними ограничениями потока данных. Одной из эталонных реализаций является предлагаемое расширение среды выполнения Quantum для JavaScript .

Объектно-ориентированный

Объектно-ориентированное реактивное программирование (OORP) представляет собой комбинацию объектно-ориентированного программирования и реактивного программирования. Возможно, наиболее естественный способ создания такой комбинации заключается в следующем: вместо методов и полей объекты имеют реакции , которые автоматически переоцениваются, когда другие реакции, от которых они зависят, были изменены.

Если в языке ООРП сохраняются императивные методы, он также подпадает под категорию императивного реактивного программирования.

Функционал

Функциональное реактивное программирование (FRP) — это парадигма реактивного программирования в области функционального программирования .

Актерский состав

Участникам было предложено разработать реактивные системы, часто в сочетании с функциональным реактивным программированием (FRP) и реактивными потоками для разработки распределенных реактивных систем.

На основе правил

Относительно новая категория языков программирования использует ограничения (правила) в качестве основной концепции программирования. Он состоит из реакций на события, которые обеспечивают соблюдение всех ограничений. Это не только облегчает реакцию на события, но и делает реактивные программы важным инструментом корректности программного обеспечения. Примером реактивного языка программирования, основанного на правилах, является Ampersand, который основан на алгебре отношений .

Реализации

• ReactiveX — API для реализации реактивного программирования с потоками, наблюдаемыми объектами и операторами с реализациями на нескольких языках, включая RxJs, RxJava, Rx.NET, RxPy и RxSwift.
• Elm (язык программирования) Реактивная композиция веб-интерфейсов пользователя.
• Reactive Streams , стандарт JVM для асинхронной обработки потоков с неблокирующим противодавлением.
• ObservableComputations — кроссплатформенная реализация .NET.
• Svelte обеспечивает реактивность в виде варианта синтаксиса JavaScript , который выглядит как JavaScript , но естественным образом является реактивным, а JavaScript обычно этого не делает.
• Solid.js обеспечивает реактивность JavaScript без изменения семантики синтаксиса JavaScript , а также реактивное создание шаблонов JSX .
• Quantum JS , расширение среды выполнения JavaScript, которое привносит в язык императивное реактивное программирование, создавая совершенно новую категорию в спектре реактивности.

См. также

• Observable (Computing) — наблюдаемый в реактивном программировании.

Внешние ссылки

• Обзор реактивного программирования. Статья Э. Байномугиши, А. Ломбида Карретона, Т. Ван Катсема, С. Мостинкса и В. Де Мойтера, опубликованная в 2013 году, в которой исследуются и классифицируются существующие подходы к реактивному программированию.
• MIMOSA Проект INRIA — ENSMP , общий сайт о реактивном программировании.
• Устаревший шаблон наблюдателя. Статья Инго Майера, Тиарка Ромпфа и Мартина Одерски, вышедшая в 2010 году , в которой описывается структура реактивного программирования для языка программирования Scala .
• Устаревший шаблон наблюдателя с помощью Scala.React. Статья Инго, 2012 г.
• RxJS , библиотека реактивных расширений для «составления асинхронных [...] программ с использованием наблюдаемых последовательностей».
• Борьба с неуклюжим отрядом реактивного программирования: модель актер-реактор. Документ 2020 года, в котором предлагается модель «актеров» и «реакторов», позволяющая избежать проблем, возникающих при объединении императивного кода с реактивным кодом.