Архитектура функционального программирования

Я знаком с объектно-ориентированной архитектурой, включая использование шаблонов проектирования и диаграмм классов для визуализации, и я знаю сервис-ориентированную архитектуру с ее контрактами и привязками протоколов, но есть что-то характерное для программного обеспечения архитектуры для системы, написанной на функциональном языке программирования?

Я знаю, что FP используется для проектов среднего и крупного масштаба. Пол Грэм написал первое воплощение Yahoo! Хранить в общем Lisp. Некоторые системы разработки lisp являются сложными. Искусственный интеллект и финансовые системы, написанные на функциональных языках, могут стать довольно большими. У всех у них есть хоть какая-то неотъемлемая архитектура, хотя мне интересно, есть ли у них что-то общее?

Как выглядит архитектура, основанная на оценке выражений? Являются ли архитектуры FP более сложными?

Обновление: Кайл напомнил мне, что SICP является хорошим ресурсом для этого предмета.

Обновление 2: Я нашел хороший пост по теме: Как функциональное программирование влияет на структуру вашего кода?

Ответ 1

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

Для отличных примеров таких проектов посмотрите XMonad, Yi и HappS. Если вы изучите, как они структурированы, вы обнаружите, что они содержат слои монадической структуры с некоторым комбинаторным клеем между ними.

Также смотрите документ Scala Experiment, в котором описывается архитектура, в которой система состоит из компонентов, которые абстрактны по их зависимостям.

Ответ 2

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

Вот очень простой пример. Это не чисто функционально, поскольку оно меняет состояние, но достаточно распространено:

(define (make-counter)
  (let ((count 0))
    (lambda ()
      (set! count (+ count 1))
      count)))

(define x (make-counter))

(x) returns 1

(x) returns 2

...etc...

Итак, у нас есть функция make-counter, которая возвращает другую функцию, которая имеет состояние счетчика внутри. Мы можем вызвать этот вновь созданный счетчик и наблюдать за изменением внутри.

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

Ответ 3

Я работал с некоторыми довольно крупными функциональными проектами. Обычно они попадают в два лагеря (по крайней мере, те, которые я использовал):

Крайняя масштабируемость/надежность/ concurrency. Транзакционные модели могут быть очень плотно скомпонованы в языке. Concurrent ML - отличный пример этого, и проекты, которые его используют, очень трудно ошибиться, если речь идет о правильности concurrency.
Разбор/модификация фреймворков. Многие из шаблонов проектирования, на которых основаны эти основы, невероятно легки в формулировании/создании/модификации на функциональных языках. Характер посетителя - отличный пример.

Ответ 4

Я распечатал и просмотрел Design Patterns в Ocaml, и они используют модули и функторы (и объекты) для воссоздания нормальных шаблонов проектирования Мы привыкли к. Это интересно, но я думаю, что они слишком много используют объекты, чтобы действительно увидеть преимущества функциональных языков. FP очень сложен, часть его природы. Думаю, мой короткий ответ - использовать модули и функторы.

Мой текущий проект довольно большой, и мы разделяем каждый модуль файлами --implicit в ocaml. Я также охотился за полным ресурсом, который мог бы иметь некоторые альтернативные взгляды или некоторые мысли о действительно успешном проекте, который вышел из проекта.

Ответ 5

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

Ответ 6

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

Список тем включает в себя:

Подходы к моделированию архитектуры с использованием диаграмм;
Анализ требований;
Встраиваемое DSL-доменное моделирование;
Внешний дизайн и реализация DSL;
Монады как подсистемы с эффектами;
Свободные монады как функциональные интерфейсы;
Стреляемые eDSL;
Инверсия управления с использованием свободных монадических eDSL;
Программная транзакционная память;
линзы;
Состояние, Reader, Writer, RWS, ST monads;
Нечистое состояние: IORef, MVar, STM;
Многопоточное и параллельное моделирование домена;
графический интерфейс;
Применимость основных технологий и подходов, таких как UML, SOLID, GRASP;
Взаимодействие с нечистыми подсистемами.

Книга основана на проектах Haskell, которые я изучаю, особенно в приложении SCADA Andromeda. Код этой книги доступен здесь. Пока книга находится в разработке (это будет сделано до 2017 года), я могу порекомендовать вам ознакомиться с моей статьей "Дизайн и архитектура в FP" здесь (Rus).

UPDATE

Я поделился своей книгой в Интернете (первые 5 глав). Посмотреть сообщение в Reddit

Ответ 7

Я думаю, что это может помочь;

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

[AIM-2002-005] Грегори Т. Салливан, Расширенные возможности языка программирования для исполняемых шаблонов проектирования" Улучшенные шаблоны посредством отражения

22 марта 2002 г.

Книга шаблонов проектирования [GOF95] представляет 24 проверенных временем шаблона, которые последовательно появляются в хорошо спроектированных программных систем. Каждый шаблон представлено описание проблема проектирования адресов шаблонов, а также примерный код реализации и соображения дизайна. Эта бумага исследует, как шаблоны из Книга "Банда четырех" или "GOF", поскольку она часто называют, появляются, когда аналогичные проблемы решаются с помощью динамический, более высокий, объектно-ориентированный язык программирования. Некоторые из паттерны исчезают, то есть они поддерживаются непосредственно языком функции, некоторые шаблоны проще или имеют другую направленность, а некоторые из них практически не изменился.