Архитектура функционального программирования - PullRequest
29 голосов
/ 18 сентября 2008

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

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

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

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

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

Ответы [ 7 ]

18 голосов
/ 19 сентября 2008

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

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

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

7 голосов
/ 07 ноября 2016

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

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

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

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

UPDATE

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

3 голосов
/ 18 сентября 2008

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

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

(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, которая возвращает другую функцию, которая имеет состояние счетчика внутри. Мы можем вызвать этот вновь созданный счетчик и наблюдать за изменениями внутри.

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

2 голосов
/ 24 сентября 2008

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

2 голосов
/ 18 сентября 2008

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

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

2 голосов
/ 18 сентября 2008

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

  • Чрезвычайная масштабируемость / надежность / параллелизм. Транзакционные модели могут быть встроены в язык очень тесно. Concurrent ML является отличным примером этого, и проекты, использующие его, очень трудно ошибиться, когда дело доходит до правильности параллелизма.
  • Парсинг / модификация фреймворков. Многие из шаблонов проектирования, на которых основаны эти платформы, невероятно легко сформулировать / построить / изменить на функциональных языках. Модель посетителя - отличный пример этого.
1 голос
/ 19 сентября 2008

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

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

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

22 марта 2002 г.

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

...