Архитектурное мышление на функциональных языках - PullRequest
26 голосов
/ 05 января 2010

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

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

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

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

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

Ответы [ 2 ]

21 голосов
/ 05 января 2010

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

Вкратце:

  • Организуйте свои приложения вокруг абстрактных типов (классы в ОО, "абстрактные типы" в FP) и операций над этими типами.

  • Используйте механизмы инкапсуляции (классы в OO, модули в FP), чтобы скрыть представления ваших абстрактных типов.

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

  • Отправляйся в город!

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

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

2 голосов
/ 05 января 2010

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

Разделение интересов; Model-Control-Presentation (во всех ее вариантах); Многоуровневая архитектура; Ввод-Процесс-Вывод и т. Д.

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

Я считаю, что шаблон ввода-процесса-вывода и конвейер преобразования шаблоны помогают.

...