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

Question

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

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

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

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

Update 2: Я нашел хороший пост на тему: How does functional programming affect the structure of your code?

Answer 1

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

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

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

Answer 2

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

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

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

(define x (make-counter)) 

(x) returns 1 

(x) returns 2 

...etc... 

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

[AIM-2002-005] Грегори Т. Салливан, Advanced Programming Language Features for Executable Design Patterns "Better Patterns Through Reflection

22 марта 2002

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

Answer 6

Надеюсь, что это не слишком тангенциально, но, возможно, интересно любому, кто просматривает ответы на этот вопрос, это презентация Design Patterns in Dynamic Programming от Peter Norvig.

Answer 7

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

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

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

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

UPDATE

Я разделил свою книгу в Интернете (первые 5 глав). See post on Reddit