Как ООАД относится к ООП, что эквивалентно функциональному программированию?

Недавно я заглянул в мир функционального программирования (FP) и задаюсь вопросом, как "мыслить функционально" даже для приложений среднего размера? Особенно w. r. t. анализ и проектирование FPs.

С помощью ООП нас учат мыслить в терминах объектов, их атрибутов и отношений. Мы моделируем наши анализы / проекты, используя диаграммы классов и последовательностей. Однако те же самые модели, похоже, плохо подходят при проектировании для FPs. Для чего существуют эквивалентные парадигмы моделирования функциональное программирование? Кажется, DFDs, возможно, хорошо подходит, но я, возможно, ошибаюсь.

Например: я думал о разработке симулятора монополии, настольной игры с использованием Haskell, просто чтобы выучить язык. При выполнении OOAD вы придумываете классы, такие как board содержит items, которые имеют атрибуты/методы, прикрепленные к нему. У вас есть player и различные другие объекты и связанные с ними отношения, которые могут быть захвачены в диаграмме классов. И их взаимодействия в диаграмме последовательности. Однако, эти парадигмы моделирования, похоже, не очень хорошо переносятся для функциональных программ. Итак, просто "как" вы моделируете функционально ?

Примечание: Я ищу конкретные ссылки/примеры, которые могут объяснить, как анализировать и проектировать функциональные программы, учитывая, что я исхожу из сильно объектно-ориентированного способа мышления/моделирования.
4 6
oop haskell functional-programming ooad

4 ответа:

В соответствии с Саймон Пейтон Джонс:

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

Источник: вдохновители программирования

Поэтому вместо того, чтобы рисовать все причудливые UML-диаграммы, вы на самом деле пишете определения типов в сочетании с undefined на этапе проектирования.
18

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

Но я полагаю, что на самом деле вы ищете какой-то совет о том, как Вы можете научиться мыслить функционально. Итак, вот некоторые мысли. При программировании в Haskell есть два способа, которыми я думаю о программе, которую пишу.

  • Если программа математическая, я думаю о программе как о наборе уравнений.

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

Итак, в вашем примере с монополией моей первой мыслью было бы выяснить, как я собираюсь представлять состояние правления (например, какие свойства имеют дома, кто ими владеет). Тогда у меня может быть функция, которая преобразует доску, когда кто-то покупает собственность и другие функции для других вещей, которые могут делать игроки. (Есть также монады для представления состояния, State и StateT. Я мог бы использовать их, если и когда я чувствую, что они сделают код более ясным, но я обычно держу вещи основными для начала.) Одной из ошибок, которые я чаще всего совершал, будучи новичком, было создание большого количества ненужных классов и типов данных.
3

Краткий ответ: состав меньших программ.

Сначала вы изучаете стоящую перед вами задачу, затем разрабатываете набор небольших операций (часто в форме комбинаторов), которые, по вашему мнению, имеют смысл в контексте этой задачи, и, наконец, строите решение вокруг этих операций. У меня сложилось впечатление, что все пакеты, найденные на Hackage, следуют этому подходу. Таким образом, окончательное решение является (чаще всего) простым, ясным и элегантным. Как вы можете оценить вышеупомянутый набор небольших операций, которые вы выбираете для своего решения, имеет решающее значение; с практикой вы разовьете чувствительность, чтобы выбрать его мудро.

Моя книга-этоЖемчужины дизайна функционального алгоритма , Ричард Берд, Google Books (preview) . В этой книге вы узнаете о вычислительном подходек функциональному программированию, который я считаю наиболее ценным.

3

Две книги, которые могут вас заинтересовать:

  1. Структура и интерпретация компьютерных программ - классическое введение к учебнику по КС в схеме. Я думаю, что это необходимо для программистов, заинтересованных в FP.

  2. How to Design Programs - аналогично SICP, немного более современно и фокусируется на дизайне. Язык выбора здесь-рэкет.

Если вы хотите практический проект в Haskell, я бы рекомендовал написать себе схему в 48 Hours , замечательный учебник по реализации интерпретатора для Scheme. Манипуляция AST-это то, где FP (и особенно Haskell) сияет, поэтому я думаю, что написание интерпретатора-хороший опыт для новых программистов FP.

2