Существует ли методология разработки программного обеспечения для функционального программирования?[закрыто]

Question

Программная инженерия, как ее преподают сегодня, полностью сосредоточена на объектно-ориентированном программировании и «естественном» объектно-ориентированном взгляде на мир.Существует подробная методология, которая описывает, как преобразовать модель предметной области в модель классов с помощью нескольких шагов и множества (UML) артефактов, таких как диаграммы вариантов использования или диаграммы классов.Многие программисты усвоили этот подход и имеют хорошее представление о том, как разработать объектно-ориентированное приложение с нуля.

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

1. Функциональные программы часто разрабатываются снизу вверх, а не сверху вниз («На Лиспе», Пол Грэм).

2. Функциональные программисты используют карты, а объектно-ориентированные программисты используют объекты/классы («Clojure для Java-программистов», доклад Рича Хикли).

Итак, какова методология систематического (основанного на модели?) проектирования функционального приложения, т.е.в Лиспе или Clojure?Каковы общие шаги, какие артефакты я использую, как мне сопоставить их из пространства проблем в пространство решений?

Answer 1

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

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

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

• Функциональные программисты используют диаграммы гораздо меньше, чем программисты OO. Многое из того, что выражается на диаграммах ОО, вместо этого выражается в типы, или в «подписях», которые вы должны думать как «типы модулей». У Хаскелла также есть «классы типов», что немного похоже на тип интерфейса.

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

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

Итак, какова методология для систематической (модели?) Конструкции функционального применения, т.е. в LISP или Clojure?

Любой метод проектирования, основанный на абстракции данных, работает хорошо. Я думаю, что это проще, когда на языке есть явные типы, но он работает даже без. Хорошая книга о методах проектирования для абстрактных типов данных, которая легко адаптируется к функциональному программированию, является Абстракция и спецификация в разработке программы Барбара Лисков и Джон Гуттаг, первый версия. Лисков выиграл награду Тьюринга частично за эту работу.

Другая методология дизайна, уникальная для LISP, - это решить, какие языковые расширения будут полезны в проблемной области, в которой вы работаете, а затем использовать гигиенические макросы для добавления этих конструкций к вашему языку. Хорошее место для чтения об этом дизайне - статья Мэтью Флэтта Создание языков в ракетке. Анкет Статья может быть за платной. Вы также можете найти более общий материал на таком виде дизайна, найдя термин «встроенный язык, специфичный для домена»; Для особого совета и примеров, помимо того, что покрывает Мэтью Флэтт, я, вероятно, начну с Грэма На LISP или, возможно, ANSI Common Lisp.

Каковы общие шаги, какие артефакты я использую?

Общие шаги:

1. Определите данные в вашей программе и операции на ней, и определите абстрактный тип данных, представляющий эти данные.

2. Определите общие действия или шаблоны вычислений и выражайте их как функции высшего порядка или макросы. Ожидайте сделать этот шаг как часть рефакторинга.

3. Если вы используете типизированный функциональный язык, используйте тип контроля рано и часто. Если вы используете LISP или Clojure, наилучшая практика состоит в том, чтобы сначала записать контракты функций, включая модульные тесты-это разработка тестов на максимум. И вы захотите использовать любую версию QuickCheck, которая была перенесена на вашу платформу, которая в вашем случае выглядит так, будто она называется Clojurecheck. Анкет Это чрезвычайно мощная библиотека для построения случайных тестов кода, которая использует функции более высокого порядка.

Answer 2

Для Clojure я рекомендую вернуться к старому старому реляционному моделированию. Из -за брезента это вдохновляющее чтение.

Answer 3

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

Мой опыт пришел от переезда из Java в Clojure в последние годы.

Некоторые примеры:

• Понять свой бизнес -домен / модель данных - Не менее важно, собираетесь ли вы разработать объектную модель или создать функциональную структуру данных с вложенными картами. В некотором смысле, FP может быть проще, потому что он побуждает вас думать о модели данных отдельно от функций / процессов, но вам все равно приходится делать оба.

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

• Тестовая разработка - Хорошо работает на языках FP, на самом деле иногда даже лучше, потому что чистые функции очень хорошо поддаются написанию четких, повторяемых тестов без необходимости настройки среды состояния. Вы также можете построить отдельные тесты, чтобы проверить целостность данных (например, есть ли у этой карты все ключи, которые я ожидаю, чтобы сбалансировать тот факт, что на языке OO определение класса обеспечит это для вас во время компиляции).

• Прототирование / итерация - работает так же хорошо с FP. Возможно, вы даже сможете прототип прототипа вживую с пользователями, если у вас очень хорошо построить инструменты / DSL и использовать их в Reply.

Answer 4

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

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

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

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

Теперь у вас есть домен, в котором у вас есть функции, которые составляют в соответствии с хорошо ведущими законами. Простой встроенный DSL!

О, и, учитывая свойства, вы, конечно, можете написать автоматические рандомизированные тесты их (ALA QuickCheck) .. и это только начало.

Answer 5

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

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

Answer 6

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

Answer 7

Смотрите мой ответ на другой пост:

Как Clojure подходит для разделения проблем?

Я согласен с тем, что на эту тему необходимо написать больше о том, как структурировать большие приложения, которые используют подход FP (плюс необходимо сделать больше для документирования FP-управляемых UI)

Answer 8

Несмотря на то, что это можно считать наивным и упрощенным, я думаю, что «рецепты проектирования» (систематический подход к решению проблем, применяемый к программированию, как это отстало. HTDP) был бы близок к тому, что вы, кажется, ищете.

Здесь несколько ссылок:

http://www.northastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

Answer 9

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

Answer 10

Я недавно нашел эту книгу:Функциональное и реактивное моделирование доменов

Я думаю, что совершенно соответствует вашему вопросу.

Из описания книги:

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

Answer 11

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

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

Answer 12

Существует стиль «Расчет программы» / «Дизайн по расчету», связанный с профессором Ричардом Бердом и алгеброй программирования в Оксфордском университете (Великобритания), я не думаю, что он слишком надуман, чтобы считать эту методологию.

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

Answer 13

Хорошо,

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

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

Я уверен, что когда функциональные ребята упадут в тупик [попытаются реализовать системы размером более 1 000 000 строк кода], некоторые из них придут с новыми методологиями разработки программного обеспечения и модными словами :-).Они должны ответить на старый вопрос:Как разделить систему на части, чтобы можно было «откусывать» каждую часть по отдельности?[работа итеративная, поэтапная и эволюционная] с использованием функционального стиля.

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

Но будут ли функциональные программы использоваться в таких больших системах? Станут ли они основным направлением?Вот в чем вопрос.

И никто не может создать реалистичную методологию, не внедрив такую ​​большую систему, запачкав свои руки.Сначала вам следует испачкать руки, а затем предложить решение.Решения-Предложения без «реальной боли и грязи» будут «фантастикой».