Functional Retroactive Programming

предыдущая серия

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

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

Далее, мы можем расшаривать эти типы данных, что автоматически означает, что любые композиции функций над ними будут корректны. А когда у нас множество «поведенческих» интерфейсов, состыковывать их обычно весьма трудоёмко.

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

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

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

Однако вышесказанное больше относится к стилю программирования (пусть и in large), нежели к проектированию архитектуры системы.

Одна из модных и весьма активно применяемых архитектур сегодня — это функциональное реактивное программирование (Functional Reactive Programming, FRP). Реактивность, в отличие от интерактивности, подразумевает достаточно быстрый ответ на входящий запрос (в пределах некоего довольно жёсткого стандарта ответа). В FRP определяются функторы Event (дискретная упорядоченная по времени последовательность событий) и Behavior (непрерывное значение, меняющееся со временем), которые можно свободно комбинировать друг с другом. Потоки таких событий и значений асинхронны.

FRP подразумевает некую «слушающую» логику: сервер ожидает входящие сигналы (события, данные) и по их поступлении проявляет некую активность. Далее мы рассмотрим более продвинутый вариант этого подхода — так называемый stream processing, когда мы отказываемся от монолитной серверной логики в пользу асинхронных «процессоров», неограниченно масштабирующихся как по горизонтали, так и по вертикали. Такой подход иногда в шутку называется Functional Retroactive Programming.
следующая серия

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *