Архитектура функционального программирования
-
01-07-2019 - |
Вопрос
Я знаком с объектно-ориентированной архитектурой, включая использование шаблонов проектирования и диаграмм классов для визуализации, а также знаю сервис-ориентированную архитектуру с ее контрактами и привязками протоколов, но Есть ли что-нибудь характерное в архитектуре программного обеспечения системы, написанной на функциональном языке программирования?
Я знаю, что FP использовался для проектов среднего и крупного масштаба.Пол Грэм написал первую версию Yahoo!Хранить в Common Lisp.Некоторые системы разработки на Lisp сложны.Искусственный интеллект и финансовые системы, написанные на функциональных языках, могут стать довольно большими.Хотя у них у всех есть хоть какая-то присущая архитектура, мне интересно, есть ли у них что-нибудь общее?
Как выглядит архитектура, основанная на оценке выражений?Являются ли архитектуры FP более компонуемыми?
Обновлять: Кайл напомнил мне об этом SICP является хорошим ресурсом по этой теме.
Обновление 2: Нашёл хороший пост на эту тему: Как функциональное программирование влияет на структуру вашего кода?
Решение
Общей нитью в «архитектуре» проектов, использующих функциональные языки, является то, что они имеют тенденцию быть разделенными на слои алгебр, а не на подсистемы в традиционном смысле системной архитектуры.
Отличные примеры таких проектов см. XМонад, Йи, и Счастье.Если вы изучите, как они структурированы, вы обнаружите, что они состоят из слоев монадической структуры с некоторым комбинаторным клеем между ними.
Также посмотрите Эксперимент со Скалой документ, в котором описывается архитектура, в которой система состоит из компонентов, абстрагирующихся от своих зависимостей.
Другие советы
Сейчас я работаю над книгой «Дизайн и архитектура в функциональном программировании».В нем описаны многие шаблоны и подходы проектирования, существующие в чистом мире ФП (основной язык — Haskell), но не только.Книга научит вас создавать с нуля большое приложение с чистым и нечистым состоянием, многопоточностью, сетью, базой данных, графическим интерфейсом, как разделить его на слои и добиться простоты.Здесь также показано, как моделировать домены и языки, как организовывать и описывать архитектуру приложения, как его тестировать и многое другое.
В список тем входят:
- Подходы к моделированию архитектуры с использованием диаграмм;
- Анализ требований;
- Встроенное моделирование домена DSL;
- Проектирование и внедрение внешнего DSL;
- Монады как подсистемы с эффектами;
- Свободные монады как функциональные интерфейсы;
- eDSL со стрелками;
- Инверсия управления с использованием свободных монадических eDSL;
- Программная транзакционная память;
- Линзы;
- Монады State, Reader, Writer, RWS, ST;
- Нечистое состояние:IORef, МВар, СТМ;
- Многопоточность и параллельное моделирование предметной области;
- графический интерфейс;
- Применимость основных методов и подходов, таких как UML, SOLID, GRASP;
- Взаимодействие с нечистыми подсистемами.
Книга основана на проектах Haskell, которые я изучаю, особенно на приложении SCADA. Андромеда.Код этой книги доступен здесь.Пока книга находится в разработке (она будет закончена до конца 2017 года), могу порекомендовать вам ознакомиться с моей статьей «Дизайн и архитектура в ФП». здесь (Рус).
ОБНОВЛЯТЬ
Я поделился своей книгой в Интернете (первые 5 глав). Смотрите пост на Reddit
Самое большое сходство, которое вы найдете в функциональных языках, — это использование функций для хранения данных.Это немного похоже на использование функций доступа к объекту без самого объекта.Вместо этого функция создается в среде, где она имеет доступ к необходимым ей данным.Теперь эту функцию можно передавать и использовать где угодно, сохраняя при этом возможность использовать данные.
Вот очень простой пример.Это не чисто функционально, поскольку меняет состояние, но это достаточно распространено:
(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, которая возвращает другую функцию, внутри которой находится состояние счетчика.Мы можем вызвать этот вновь созданный счетчик и наблюдать за изменениями внутри.
Именно так структурированы функциональные программы.У вас есть функции, которые принимают функции в качестве аргументов, есть функции, которые возвращают функции со скрытым состоянием и т. д.Это намного проще, чем управлять памятью самостоятельно.
Я работал с некоторыми довольно большими функциональными проектами.Обычно они делятся на два лагеря (по крайней мере, те, которые я использовал):
- Чрезвычайная масштабируемость/надежность/параллелизм.Транзакционные модели могут быть очень плотно встроены в язык.Параллельное машинное обучение является отличным примером этого, и в проектах, которые его используют, очень трудно ошибиться, когда дело касается корректности параллелизма.
- Разбор/модификация фреймворков.Многие шаблоны проектирования, на которых основаны эти фреймворки, невероятно легко сформулировать/создать/модифицировать на функциональных языках.Шаблон посетителей является отличным примером этого.
Я распечатал и посмотрел Шаблоны проектирования в Ocaml, и они используют модули и функторы (и объекты) для воссоздания обычных шаблонов проектирования, к которым мы привыкли.Это интересно, но мне кажется, они используют предметы слишком многое, чтобы действительно увидеть преимущества функциональных языков.FP очень легко компонуется, это часть его природы.Я думаю, мой короткий ответ - использовать модули и функторы.
Мой текущий проект довольно большой, и мы разделяем каждый модуль по файлам — неявно в ocaml.Я также искал всеобъемлющий ресурс, в котором могли бы быть какие-то альтернативные взгляды или мысли о действительно успешной конструкции, возникшей в результате проекта.
Надеюсь, эта презентация не слишком второстепенная, но, вероятно, интересна для всех, кто просматривает ответы на этот вопрос. Шаблоны проектирования в динамическом программировании Питер Норвиг.
Я думаю, это может помочь;
Некоторые из шаблонов исчезают, то есть они поддерживаются непосредственно языковыми функциями, некоторые шаблоны проще или имеют другое внимание, а некоторые по сути не изменяются.
[AIM-2002-005] Грегори Т.Салливан, Расширенные возможности языка программирования для исполняемых шаблонов проектирования «Улучшение шаблонов посредством отражения»
22 марта 2002 г.
Книга дизайна [GOF95] представляет 24 проверенных временных шаблонов, которые последовательно появляются в хорошо разработанных программных системах.Каждый шаблон представлен с описанием задачи проектирования, которые образуют адреса шаблона, а также пример кода реализации и соображения проектирования.В этой статье исследуется, как шаблоны из «банды четырех», или книги «GOF», как часто называют, появляются, когда подобные проблемы решаются с использованием динамического языка программирования более высокого порядка.Некоторые из шаблонов исчезают, то есть они поддерживаются непосредственно языковыми функциями, некоторые шаблоны проще или имеют другое внимание, а некоторые по сути не изменяются.