Архитектурное мышление в функциональных языках

Поле "Мои вопросы" переполняется вопросами функционального программирования. Пересмотрев наиболее релевантные, мне все еще интересно услышать мнения о следующем:

Как вы думаете о структурировании приложения на функциональном языке?

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

Как и многие, мое первое знакомство с инкапсуляцией и повторным использованием кода происходило из фона OO. Поскольку я изучал разные языки, функциональное программирование действительно привлекло мое внимание. Я начинаю понимать преимущества неизменности, функций более высокого порядка и т.д. Но я все еще теряю чувство структурирования функционального приложения, не отступая от концепций OO. Фактически, многие из функциональных примеров, которые я видел, имеют больше общего с кодом спагетти, хотя я уверен, что из-за простоты примеров, а не из-за каких-либо неотъемлемых недостатков в функциональном подходе.

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

Ответ 1

В конце 1970-х годов Барбара Лисков и другие разработали лодку крупномасштабных методов "объектно-ориентированного проектирования", которые до сих пор широко используются сегодня и которые не изменяются до функционального программирования. Они проще всего применять на языке с явными интерфейсами и реализациями, что означает стандарт ML (где интерфейсы называются "сигнатурами", а реализации называются "структуры" или "функторы" ) или Objective Caml (где интерфейсы называются "типами модулей" ", а реализации называются" модулями "). Если вы предпочитаете Scheme, то" единичный" язык, разработанный Мэтью Флаттом и Маттиасом Феллезином, встроен в PLT-схему и является очень хорошим способом выражения крупномасштабных функций.

Вкратце:

Организуйте свои приложения вокруг абстрактных типов (классы в OO, "абстрактные типы" в FP) и операции над этими типами.
Используйте механизмы инкапсуляции (классы в OO, модули в FP), чтобы скрыть представления ваших абстрактных типов.
Структура вашего приложения, чтобы каждая реализация зависела от других реализаций косвенно через их интерфейсы. Таким образом, вы ограничиваете объем кода, который вы должны понимать, для создания или изменения какой-либо одной части вашего приложения.
Пойдите в город!

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

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

Ответ 2

Большинство общих шаблонов проектирования полностью применимы:

Разделение проблем; Model-Control-Presentation (во всех его вариантах); Многоуровневая архитектура; Input-Process-Output и т.д.

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

Я нахожу, что шаблоны input-process-output и конвейер конвейера помогают.